in reply to Re^2: Configuration files
in thread Configuration files

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.

Replies are listed 'Best First'.
Re^4: Configuration files
by keyslapper (Novice) on Jan 01, 2005 at 18:57 UTC
    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 :)
      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.

        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.