Re4: Moving Perl from test to Dev

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.

Comment on Re4: Moving Perl from test to Dev

Replies are listed 'Best First'.
Re: Moving Perl from test to Dev by Abigail-II (Bishop) on Nov 21, 2003 at 14:11 UTC
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. That's pretty dangerous! There are people that cleanup their CPAN directories, and only keep the most recent version(s) of their modules there. What if you want to do "install XXX 1.234", and the oldest version of XXX on CPAN happens to be 4.17? Abigail	[reply]
Re: Re: Moving Perl from test to Dev by dragonchild (Archbishop) on Nov 21, 2003 at 14:17 UTC
I didn't know that! Huh. So, local copies of the .tar.gz it is! ------ 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.	[reply]
Re^5: Moving Perl from test to Dev by adrianh (Chancellor) on Nov 21, 2003 at 14:19 UTC
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. The problem with this approach is that you cannot trust CPAN to have that version available. Old modules are deleted on a regular basis by their authors (I certainly do). I have a vague memory of this being a "best practice" documented somewhere, but I can't locate it after five minutes googling so I may be mis-remembering. Yes, there are things like backpan, but now you have to deal with CPAN, backpan + your own modules. I'm in complete agreement with chromatic, keeping everything in source control makes development much easier IMHO. My /vendor directory of my current project includes all third party modules, plus perl, apache, mod_perl, openssl, and all other third party code. I want everything that I need to build my project available locally and under source control so that I can access it easily at any point in the future.	[reply]