matstnilsson has asked for the wisdom of the Perl Monks concerning the following question:

Hi!

I have an intresting problem for our programming community on Solaris.

I want to develop an environment where:

1) The developers shouldn't need to bother about which Perl version to use.
2) When the Perl version is changed in a controlled manner, the change should be instant.
3) For developers whose scripts fails after a Perl version change, there should be a roll-back possibility.

The infra structure in our department provides a cornucopia of Perl versions.

These are installed under eg. /app/perl/5.8.1/bin/perl

Furthermore, to support a specific version of Perl you have to run a script that modifies your $PATH so that that specific Perl is found first in the PATH.

Some solutions that I have tried:

Solution 1:
Put the explicit path to your Perl interpretator as the magic line, eg: Of course, you have to run the script that modifies your PATH prior to the script execution.
A script example:

#!/app/perl/5.8.1/bin/perl printf "Hello, World!\n";

The drawback is that you have to update gazillions of magic lines when we change to a new Perl version.

Solution 2:
Use a symbolic link to point to your current Perl version. Still you have to run the script that modifies your PATH prior to the script execution.
A link example:

ln -s /app/perl/5.8.1/bin/perl /home/foobar/current_perl A script example: #!/home/foobar/current_perl printf "Hello, World!\n";

The (smaller) drawback is that you have to edit the magic line if you deliberately want to override the Perl version.

Solution 3:
Use a wrapper that selects a Perl from the path. Still you have to run the script that modifies your PATH prior to the script execution.
A script example:

#!/usr/bin/env perl printf "Hello, World!\n";

If you don't like the selected Perl you can re-modify your PATH an continue.

Additions requirements: When investigating this I found that you sometimes want to save your scripts in a CM-system, eg. ClearCase. Furthermore you want to execute old verions of a script with that old Perl version that existed when it was developed.

Solution 4: (A combination of 2 and 3)
First you have a symbolic link in your CM-system that points to your selected Perl version. This link is baselines along with the script source.
A link example:

ln -s /app/perl/5.8.1/bin/perl /vobs/foobar/current_perl

Secondly, you have a better wrapper that you put in the magic line:
A script example:

#!/vobs/foobar/perlwrapper printf "Hello, World!\n";

The wrapper does ths following: 1) Checks if the environment (PATH etc.) is compatible with the Perl that is pointed to by the symbolic link.
2) If not, the environment is adjusted, using the script mentioned above.
3) Starts Perl with the proper arguments.

Now my problem:
Where to find info of how to write such a wrapper.

Regards

20031210 Edit by Corion: Removed code tags, added formatting

janitored by ybiC: Balanced <readmore> tags around example solutions

Replies are listed 'Best First'.
Re: Wrapper on magic line
by Abigail-II (Bishop) on Dec 10, 2003 at 10:42 UTC
    Checks if the environment (PATH etc.) is compatible with the Perl that is pointed to by the symbolic link.
    What do you mean by an environment being compatible with a version of Perl?

    How about the following situation: Keep your /app/perl/VERSION/ structure. Let /usr/bin/perl be a symbolic link to newest perl (for instance /app/perl/5.8.2/bin/perl). Developers use #!/usr/bin/perl by default. If you need a roll-back, change the first line to #!/app/perl/WHATEVER/bin/perl.

    So, developers don't need to do anything if a new version of perl gets installed, unless a new version breaks their program. Then they only have to perform a one line fix for each program that breaks. I'm not sure you are looking for a way to automatically detect whether scripts will fail and then fallback, but that's something I wouldn't do myself.

    Abigail