Re: How to manage the transfer of large Perl environments from one network to another

[hippo]

the PERLLIB environment variable captured at the customer site has over 430 directory entries.

I can't be the only one who read that (twice to make sure I hadn't mis-read) and immediately thought how impressively horrendous it is. You have my sympathy.

what would be the best method to verify that the captured Perl environment at the customer site unpacks and runs smoothly on my employer's network?

Obvious answer: run the test suite. Now I'm going to assume that an organisation that has ended up with 430 entries in $PERLLIB probably doesn't have a test suite. So your first task is to write one. I would start by writing a test which just compiles everything in turn. That way you can run the test, keep adding to @INC or whatever needs to be done to get things to compile without breaking the ones you've already fixed. This will be a lot of work but it's sure to pay off in the end.

Actually, I posted this Q on Stack Overflow and the first response was to post here.

That's fine but if you could link to that SOQ then it will save possible duplication of effort in replying. Thanks.

[fiddler42]

Yes, regarding PERLLIB, you read it right. To be exact, there are 439 entries, which collectively radiate cold shafts of broken glass in every direction imaginable. :-/

Could you kindly shed some light on what you mean by a test suite? I am asking because, typically, Perl scripts are run to initialize a chip-building environment by parsing configuration files and settings, etc., and then a non-Perl compiled binary is fired up for what can sometimes be a multi-day run. Now, I could skip the non-Perl compiled binary activity for testing purposes. The different Perl scripts, though, are run from one wildly different location to another. Are you saying a master/test Perl script should be used to appropriately augment @INC as each chip-building Perl script fails? In other words, at the start of test suite activity, empty @INC and build it out to include only what is necessary.

Pardon my ignorance, but I am not familiar with setting up test suites in Perl. Typical Perl scripts that I author, for example, require only a handful of custom modules, so this is turning out to be quite the learning experience for me...

[hippo]

Could you kindly shed some light on what you mean by a test suite?

As luck would have it I am currently trying to produce a gentle introduction to testing in Perl. You can read the work in progress on my scratchpad. (Update: This document has now been published as Basic Testing Tutorial). In essence a test suite is a set of code which verifies how some other code is expected to behave. Ordinarily this is barely little more than a sequence of subroutine or method calls with associated test data but in your case can be as simple as trying to compile a catalogue of scripts. Your Perl scripts will either compile or not but you can (presumably) attempt to compile them without running and thereby do no damage.

Are you saying a master/test Perl script should be used to appropriately augment @INC as each chip-building Perl script fails?

Not exactly. The test suite is there just to test and should be idempotent. You could, if you so wish, construct another script to perform the augmentation and then subseqently use the test script to assess its effectiveness. Test scripts (and suites) exist for a number of reasons but regression is not the least of them. If you adjust $PERLLIB to fix one script you must ensure that doing so does not break another. This is one of many areas where automated testing proves its worth.

[wagnerc]

I think one very important question to ask first, is what do you want the system to look like after this clean up is completed? Or is the task to merely document the current disorder?

Chris