"#!/usr/bin/env perl" and using multiple environments

Scott Penrose scottp at dd.com.au
Mon May 26 19:56:43 CDT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Monday, May 26, 2003, at 23:54 Australia/Melbourne, Timothy S. 
Nelson wrote:

> On Sun, 25 May 2003, Bradley Dean wrote:
>
>> Greetings folks,
>>
>> I've been considering the potential benefits of using some sort of
>> self-rolled /usr/bin/env in project development when multiple 
>> environments
>> are needed.
>>
>> For instance - if a projects development, testing and production
>> environments use entirely separate module libraries, it would be nice 
>> not
>> to have to hard code the appropriate 'use lib's.
>>
>> Now env soes have the ability to let you change specific environment
>> variables, but if their are lots of changes that's going to lead to a 
>> messy
>> #! at the start of each script.
>>
>> The alternative I'm considering is to have something like:
>>  - env-dev
>>  - env-test
>>  - env-prod
>
> 	Hmm.  You could also make one called "envconf", which pulls its
> configuration from a file, and then you just pass it a command line 
> parameter,
> eg.
>
> envconf -e dev
> envconf -e test
> envconf -e prod
>
> 	That would cut down on the number of files littering your system,
> would make it easy to add extra environments, and would give the tool a
> greater general applicability than just your own project.  Then 
> there's less
> code duplication as well :).  I don't see any reason why it wouldn't 
> work, but
> neither am I a super-guru :).

I agree about putting it in a file - eg: /etc/env.conf
However, I would go for a file and / or symlink version.

>> Which essentially do the same thing as env, but with a (dev|test|prod)
>> environment built.
>>
>> This way the #!'s become '#!/somepath/env-dev perl' for instance and 
>> al;
>> should notionally be well (and there should be no need for any hard 
>> coding
>> of specific 'modes' within the code itself)

The problem with this approach is you haven't really saved much.
You still have to then change all your code from env-dev to 
env--production
Instead if you do it in a config and/or symlinks to env
Then your #! is just
	#!/usr/bin/env perl

and you symlink /usr/bin/env to /usr/bin/env-dev  on the dev box, and 
to something else on other boxes.
Or you just have a file in /etc/env.conf which is the environment 
details, and just change that file.

You could even have an environment variable (sounds recursvive, but not 
really).
eg:
	ENV_CONF=/etc/env_beta.conf

so that you can have multiple environments on the one box, and still 
only have one #!

Scott

>> It also means that a general environment can be built up so the
>> env-(dev|test|prod) can be used to construct all environments, not 
>> just the
>> perl #!'s
>>
>> Anyone seen this sort of thing done, have any thoughts on the matter?
>
> ---------------------------------------------------------------------
> | Name: Tim Nelson                 | Because the Creator is,        |
> | E-mail: wayland at smartchat.net.au | I am                           |
> ---------------------------------------------------------------------
>
> ----BEGIN GEEK CODE BLOCK----
> Version 3.12
> GCS d+ s:- a- C++>++++$ U++ P++ L++ E- W+++ N+ w>--- V- Y+>++
> PGP->++ R !tv b++ DI++++ D+ G e++>++++ h! y-
> -----END GEEK CODE BLOCK-----
>
>
>
>
>
- -- 
Scott Penrose
VP in charge of Pancakes
http://linux.dd.com.au/
scottp at dd.com.au

Dismaimer: If you receive this email in error - please eat it 
immediately to prevent it from falling into the wrong hands.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE+0rfPDCFCcmAm26YRAnTiAKCfpXzXBKKLVXS9PEeVygDWo2vLWACaAoky
2cS+LnI2b3iZIA0gg8WZPac=
=WM/T
-----END PGP SIGNATURE-----




More information about the Melbourne-pm mailing list