Env::Export

Ovid on 2009-03-13T15:44:53

You know, %ENV needs some love. I'm thinking something like this:

use Env::Export qr/^PIPS/;

if (ENV_PIPS3_DEBUG) { # %ENV{PIPS3_DEBUG}
    my $db_name = ENV_PIPS3_TEST_DB;
}

Easier to type and no more wondering why $ENV{PIPS_DEBUG} is false. Compile-time failures for the win!

Is this on the CPAN? I don't see it.


Env

rjray on 2009-03-13T21:35:58

The closest I can find is the "Env" module, which ties environment variables to scalars or arrays, for sugary purposes.

Let me know if you don't think you'll get around to this, and I'll be glad to throw something up on GitHub :-).

Re:Env

Ovid on 2009-03-14T08:18:21

Feel free to do this. It's great if I just think of ideas and others implement them :) Curiously, as you can see from replies below, some folks don't like this idea.

I hope you're not serious

Ron Savage on 2009-03-13T23:40:42

Hi Ovid

All you're doing is adding obfuscation to %ENV.

Big mistake.

Re:I hope you're not serious

Ovid on 2009-03-14T00:19:57

Diagnosing $ENV{FEILD} is better? What's your solution?

Re:I hope you're not serious

btilly on 2009-03-14T02:59:37

Hash::Util's lock_keys seems like a good solution to me.

Re:I hope you're not serious

Ovid on 2009-03-14T08:01:42

Except that sometimes people need to add environment variables. Boom!

Re:I hope you're not serious

tsee on 2009-03-14T09:32:58

Exactly right. At the very least, using PAR would be entirely out of the question. And you never know when someone down the road thinks *your* deployment strategy sucked big time and wants to do it over differently.

Re:I hope you're not serious

btilly on 2009-03-14T12:14:13

There is also an unlock_keys function for that case. And then if you're paranoid, you re-lock it. And if you want to use PAR later, you can have lock_keys be done conditionally depending on whether you are in your development environment or are all packaged up with PAR.

My experience is that using lock_keys to cause typos in hash accesses to blow up has a similar effect on catching my typos to strict. Albeit with a performance overhead. And the bonus is that it works for any kind of hash.

An example where I use this is that in certain kinds of data processing it is nice to set up an array of anonymous hashes with locked keys. Then any typos in your hash accesses are caught right away with no debugging needed. And if you need to for performance reasons, you can easily remove the lock_keys call once the code is developed.

Re:I hope you're not serious

Ron Savage on 2009-03-14T09:19:40

If not Hash::Util, then perhaps Internals could be put to use:

http://search.cpan.org/user/stbey/Internals-1.1/Internals.pm

Here's an implementation

tsee on 2009-03-14T10:16:29

Here's a simple implementation. (I think Env::Constant is a better name than Env::Export) You can find it with some basic tests and docs at http://svn.ali.as/cpan/trunk/Env-Constant. Contact Adam Kennedy if you want commit access to that repository*.

package Env::Constant;

use 5.006001;
use strict;
use warnings;
use Carp qw/croak/;

our $VERSION = '0.01';

sub import {
    my $class = shift;
    my $matching_keys = shift;
    $matching_keys = eval {qr/$matching_keys/}
        if defined $matching_keys and not ref($matching_keys) eq 'Regexp';
    croak("Invalid regular expression specified: $@")
        if $@;

    my ($calling_pkg) = caller();
    croak("Could not determine caller package")
        if not defined $calling_pkg or $calling_pkg eq '';

    foreach my $envkey (keys %ENV) {
        next if defined $matching_keys and $envkey !~ $matching_keys;
        if ($envkey =~ /\W/) {
            warn "The environment variable '$envkey' contains invalid characters. Must match /\\w/ for exporting";
            next;
        }

        my $varname = "${calling_pkg}::ENV_$envkey";
        my $value = $ENV{$envkey};
        no strict 'refs';
        *$varname = sub () { $value };
    }
}

* On an aside: nobody dare give me a "SVN sucks" rant on this.

Re:Here's an implementation

Ovid on 2009-03-14T11:32:10

I certainly won't give you grief for Subversion. If it's good enough for you, that's fine. It's when people tell other people that "my solution should be your solution" that it's worth asking if that solution is optimal.

Re:Here's an implementation

tsee on 2009-03-14T12:17:07

Oh, my comment wasn't targetted at you specifically. What you're saying is exactly my point of view. I even think that perl moving to git was one of the best things to happen to it in the past years.

Re:Here's an implementation

rjray on 2009-03-15T01:27:17

I can actually think of ways this can be useful (beyond what others in this thread have dismissed), and might actually craft something as a proof-of-concept. Do you mind if I borrow/adapt some of your code as a starting point?

Re:Here's an implementation

tsee on 2009-03-15T10:27:42

Hi Randy,

feel free to use whatever you like. I'd suggest taking it from SVN where there's also a bit of documentation and a few basic tests.

Cheers,
Steffen

Why not Env?

Aristotle on 2009-04-16T07:13:19

Variable names in combination with strictures seem to me to enjoy more reliable compile-time detection than subs; as well, they’re easier to use in all sorts of ways (cf. the PBP arguments against the constant pragma).