honegrown module placement

[chexmix]

Good morning, Monks:

My department is assuming management of its own Perl installation, and we're using perlbrew to simplify this. So far I have to say the setup has been pretty smooth, but I have run up against a question I'm not sure how to answer:

We have a number of home-grown modules (e.g. things that are not on CPAN and have little (well, no) reason to go there because they are so specific to the ways we do things here.

I'm not sure where in the module hierarchy such things should go. Maybe it doesn't matter as long as we are consistent?

My first impulse was to create a subdirectory under site-perl, named after our department, and put our modules in a tree beneath that subdirectory ... but maybe there is a better option.

Am I just making this more complicated than it is? ;^) It certainly wouldn't be the first time I'd done so ...

Thanks,

G

[rjt]

There are two issues:

Module Namespace

For this, anything not likely to be ever used on CPAN is fair game. Using your company and/or project name is usually a good bet, e.g., AwesomeCo::Thingy, but anything that makes sense to you will do, really.

Module Installation

Let the module's Makefile.PL / makefile handle this; it will do the right thing, and makes it much easier to distribute. If your modules do not have a standard build structure, may I suggest the 8-year-old but still relevant José's Guide for creating Perl modules, which suggests Module::Starter and ExtUtils::ModuleStarter, in addition to h2xs. Pick whatever works best for you.

Even with existing module code, it is trivial to have one of the above utilities create a skeleton, and then you drop your existing code into the lib directory, and probably tweak the Makefile.PL and MANIFEST to suit (and hopefully add some unit tests!)

[tobyink]

Personally I would package the modules using standard CPAN tools, but simply not upload them to CPAN; keep the packages in a local archive.

For bonus points though, manage that local archive with Pinto, providing you with a CPAN-like repository so that standard CPAN clients (e.g. cpanm) can install them without any hassles.

[jfroebe]

If the home grown modules will never see the light outside your company, simply put the modules in your company's namespace. For example, Loony Tunes could be LoonyTunes::Monitoring::Coyote::RoadRunner

Whether you want to create the modules using one of the myriad of CPAN ways or just put them in a directory (adding to PERL5LIB or "use lib ...") is purely up to you :)