Abigail

That works great if your environments are on different systems. All you have to do is move your scripts over from one environment to the other and they should work immediately if perl is in the same location (such as "/usr/freeware/bin").

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

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

For sure you will run into problems in a Windows environment where various DLL-modules will need to be properly registered or else they may fail.

CountZero

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

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

I use rsync myself. Using a variation of making backup snapshots using rsync it's easy to copy an entire tree around and have a handy backup snapshot if it all goes horribly wrong.

Have you considered keeping everything (including external modules) in source control?

I recommend against the external modules in source control. What are you checking in? If it's gzips, then that's no good. If it's the pm's, then you have a concurrency issue.

Personally, I'd keep a checklist of steps to take, preferably in some script. That way, you can (re)build your environment on (nearly) any machine known to man. Kick the script off, then go home for the night. :-)

Personally, I have a small "install" script that will go through source control and copy over things that have changed. It works for me ...

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Personally, I'd keep a checklist of steps to take, preferably in some script.

Yep. That's what I do too. And the "script" is almost always called "Makefile". I love make. I use it everywhere. ;-)

Abigail

What concurrency issue?

If you want to be sure that you have the same version of modules on the development box as on the production box, you need to keep local copies somehow. Setting up your own CPAN mirror would also work.

You may not think you'd want this, but there several useful CPAN modules that have occasional backwards-incompatible changes. Hoping you won't run into that isn't nearly as effective as making sure it won't bite you.