How does its being distributed affect this? Presumably the admins have measures to untar a file remotely, yes? Just place the module files in the directory the script is in and have people run from there or set their perl include paths.
But I agree with what other people have said about how not being able to install stuff is based on the wrong reasons. In the general case you *will* eventually want to use other people's module -- or your own, in .pm files -- and it is will cost your employers money not to allow you to do that. | [reply] |
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 :)
| [reply] |
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] |