Re^4: Configuration files

Agreed. Problem is I personally have no access whatsoever to the environment the script is expected to run in. The Perl installation is homogenous over a network of hundreds of machines, so getting it upgraded or modified is a serious undertaking - not that it isn't automated in some way, just that changing something on so many systems is not done lightly - nor should it be.

If I want something included as a dependency of the project, I pretty much have to include it as part of the project. I probably have the option of simply including the .pf file in the CVS package, but then I have a lot of questions to answer concerning duplication, security of the module, etc.

This is starting to get interesting :)

Comment on Re^4: Configuration files

Replies are listed 'Best First'.
Re^5: Configuration files by gaal (Parson) on Jan 01, 2005 at 19:09 UTC
Are you the only Perl guy there? Then tell them they have the option of trusting you to write an extra bug-free module in time they hadn't budgeted for, or trust you to review some options from CPAN. Factoring out, they don't have the option of not trusting you :) If you have other Perl people there, you can get them involved. With any luck they will be on the side of code reuse. Speaking of which, of course using a module helps against duplication! You mentioned the perl installation several times. Keep in mind that you do not have to change it. Just as your main script will be copied over to n machines, so can the modules you need.	[reply]
Re^6: Configuration files by szabgab (Priest) on Jan 02, 2005 at 07:26 UTC
One of the solutions I saw often in similar situations is that the developer takes a real CPAN module, renames it (eg. turn YAML in to MyNameSpace::YAML) and that's it. I don't really like this solution and I am glad so far I did not have to do this, but this might help. This might also give you the opportunity - or the need - to actually read the source code of the module.	[reply]