perl: new cpan module maker? local configuration text files and executables, too?

8
votes

I am writing a perl program that I want to share with others, eventually via cpan. it's getting to the point where I should start thinking about this on a bigger scale.

  • a decade ago, I used the h2xs package maker once. is this still the most recommended way to get started? there used to be a couple of alternatives. because I am starting from scratch with very little recollection, anything simple will do at this point.

  • I need to read a few long text files (not perl modules) for configuration. where do I put them and how do I access them, no matter where the module is installed? (FindBin?) _DATA_ is inconvenient.

  • I need to provide an executable (linux and osx). can putting an executable into the user's path be part of the module installation? (how?)

  • I would like to be able to continue developing it, run it for test purposes, have a new version, repack it, and reupload it easily.

  • before uploading to cpan, can I share a cpan bundle for easy local installation to downloaders and testers?

    # cpan < mybundle.cpanbundle

advice appreciated.

regards,

/iaw

2
perlcpan

2 Answers

5
votes

If anything I say conflicts with Andy Lester, listen to him instead. He knows more than I ever will.

  • Module::Starter is a good, simple way to generate module scaffolding. My take is it's been the default for this sort of thing for a few years now.

  • For configuration/support files, I think you probably want File::ShareDir. Might be worth considering Data::Section if it's just a matter of needing multiple __DATA__ sections though.

  • You can certainly put scripts in the bin subdirectory of your distribution, the build tool will put it in the right place at install time.

  • A build tool will take care of the work-flow you describe.

  • Bundles are something different. You make a distribution and share the tarball/archive.

If you set up PERL5LIB appropriately, then repeat make test, make install, make dist to your heart's content. For development/sharing purposes a lot of projects do their work on github or similar - makes it easy to share. They have private accounts for business purposes too. Very useful if you want to rewind and see where/when a problem was introduced.

If you get a copy of cpanm (simple to install, fairly lightweight) then it can install from a tar.gz file or even direct from a git repository. You can also tell it to install to a local dir (local::lib compatible - another utility that's very useful).

Hopefully that's reasonably up-to-date as of 2014. You may see Dist::Zilla mentioned for module development. My understanding is that it's most useful for those with a large family of CPAN distributions to manage. Oh - if you (or other readers) aren't aware of them, do check out autodie and Try::Tiny around errors and exceptions, Moose (for a full-featured object-oriented framework) and Moo (for a smaller lightweight version).

I think that advice is all reasonably non-controversial. I find cpanm to be much more pleasant than the "full" cpan client, and Moo seems pretty popular nowadays too.

4
votes

Take a look at Module::Starter and its much more capable (and complex) successor Dist::Zilla.

Whatever you do, don't use h2xs. Module::Starter was created specifically because h2xs was such an inappropriate tool for creating distributions.