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 ...

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.

Keeping track of which versions you have installed where is the first step to making sure you won't ever have to say: "But it worked on my machine ..." (This is a major complaint I have with a current freelance customer of mine ...)

Personally, I'd prefer to let CPAN do the source-control on those modules and install the specific version of a given module in each place. For example, you could either d/l the correct .tar.gz or do "install XXX 1.234" within the CPAN module.

------
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.