Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

honegrown module placement

by chexmix (Hermit)
on Jun 03, 2013 at 14:20 UTC ( #1036768=perlquestion: print w/replies, xml ) Need Help??

chexmix has asked for the wisdom of the Perl Monks concerning the following question:

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 ...



Replies are listed 'Best First'.
Re: honegrown module placement
by rjt (Curate) on Jun 03, 2013 at 14:32 UTC

    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!)

Re: honegrown module placement
by tobyink (Canon) on Jun 03, 2013 at 14:49 UTC

    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.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: honegrown module placement
by jfroebe (Parson) on Jun 03, 2013 at 14:23 UTC

    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 :)

    Jason L. Froebe

    Blog, Tech Blog

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1036768]
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2022-08-14 09:53 GMT
Find Nodes?
    Voting Booth?

    No recent polls found