> I don't know if this [specific] module is "standard" > or not, but it was already installed on the servers, > so I am guessing it is.
I don't think it is, or at least it wasn't installed by doing a full install of ActiveState Perl 5.8 in my case. Perhaps the "real" Perl distribution differs from ActiveState Perl on what modules it includes by default? If not, you might just have a precedent you can use to get them to install other modules! :-) > But would you agree, that at least in some cases, > it is "almost" as hard to use and understand a CPAN > module then to write your own? But using my argument that if you write your own code to do one thing, you might have to write your own code to do some other related thing in the future, then learning how to use this module that probably does all you need to do will pay off in the long run. I hear you about docs, though. And sometimes, even good docs don't help that much, because what you need to do is very very specific... That's just part of the game. > But I've used some modules from CPAN just as this > group suggest <grin> just to find out it had a bug in it. That's one of the evils of the "release early and often" philosophy of Open Source. The counterpoint of that being that it will probably improve quickly, especially if you're not the only person who finds that functionality potentially useful. People (maybe you?) will pick it up, fix a bug here, another there, and re-upload it. If the maintainer's email is dead, someone else will probably even take up maintainership of the module! That's one of the beauties of this model, it's very organic. As long as someone finds something useful, it will prosper. > [...] they (naively) feel that it would adversely > affect the perl executable itself and/or other > application developers using 'perl'. That's one of the conceptual problems you'll have to work out with them, unfortunately. You can only remove those false conclusions by telling them what a module is/does in general, and that code that doesn't 'use' the module should not be affected. > Another responder to this question also suggested > to at least evaluate the code from the module so > as not to completely re-invent the wheen (good > suggestion, BTW). I'm not sure if this amounts to the same thing, but you could make a directory parallel to all your projects (where I assume you have access), say /prod/lib, and put the modules there, in the same directory structure as they would be in /usr/perl/lib or /usr/perl/site/lib. From there, you can add that path to your library path with 'use lib "/prod/lib";' and then 'use' modules from there as if they were in the Perl install. This allows you to put modules there (be sure to have an identical structure on your development server) and not actually install anything directly into the Perl distribution directory. Good luck, J-S -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
