But what if you have your staging environment on the same system as your test environment? It seems that there would be a few decisions to make. If separate copies of the same version of perl must be maintained for some reason (i.e., for backup or other portability issues), then installing perl in a default location such as "/usr/freeware/bin" may not be good.

It seems that you would want to set up separate directories, one for test, one for dev, each containing an installation of Perl. For ease of switching between versions, you could either change the symbolic link "perl" to point to your desired version, or alter the #! line in every script when rolling them from dev into test. Neither of those seem to be great options.

I'm not offering solutions, here, just points to consider. Perhaps someone else has gone through this and has a much more efficient solution.

If your test environment and your development environment are on the same box, you have a problem. Either they use the same perl (not desirable, otherwise you can't upgrade/replace the perl in one place, while not touching the other), or you have them at different locations. But then your test environment is different from your development environment, and that's far from ideal as well.

I strongly recommend against that. Otherwise, you might be able to get away with just reconfiguring/compiling/installing perl, and copying the locally installed modules. Or you might want to search for 'relocatable perl's. It seems to work on some OSses (OS/2 for instances), and some people (Redhat?) have success with configuring perl with a huge default @INC, and a binary edit of Perl. I don't think perl relocation is officially supported though.

Abigail

But then your test environment is different from your development environment, and that's far from ideal as well.

This is an excellent point. I've been in situations, though, where the development site did not have a budget that would allow for even one extra system to use as a test environment.

It was definitely not the ideal situation.

Add a step for ActivePerl on Windows systems. Run the reloc_perl script from the bin to "relocate perl" and see ActiveState and the script itself for docs.

welchavw

The only adminny thingies I've ever done on a Windows machine are 1) setting an IP address and 2) asking someone to install Cygwin for me.

You've given me another reason to keep it that way.

Abigail

Hmmm....I have never hit any problems in this regard. My understanding is that DLLs will never need to be "registered" unless they do OLE-ish kinds of things. My guess is that I have never needed to use any OLE-ish perl DLLs on Win32. I copy perl installations around to different Win32 hosts quite frequently and run reloc_perl and its been all smooth sailing. Are you just guessing that various modules will fail or can you cite examples? I would be interested to know what you have found necessary to avoid.

,welchavw

A good point you have here.

As long as all the DLL's are in the perl-tree and are "dynaloaded" it will work, but I can imagine that some modules might put the DLL's elsewhere and then simply copying the perl-tree will not work.

I was thinking of things like expat or sablotron which use their own dll's in their own folders and with which I had no end of trouble getting them to run after I upgraded my perl-installation.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law