Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tomhukins (4457)

tomhukins
  (email not shown publicly)

Perl, Web, Database developer, and Milton Keynes Perl Monger [pm.org].

Journal of tomhukins (4457)

Tuesday November 03, 2009
03:27 PM

Using CPAN's Toolchain to Improve Your Code

[ #39835 ]

I've given a talk on using the techniques as CPAN authors use in their public code in your private code twice this year: originally at Milton Keynes Perl Mongers in April, then at YAPC Europe in August.

And finally I have put my slides online!

I have noticed that most companies arrange their code in an unstructured way, and contrasted this to how CPAN arranges code as small distributions packaged with documentation and tests. I advocated the idea of taking this approach with other Perl code, even if it will never live on CPAN.

I got some useful feedback after my talk and had several interesing discussions about it at the conference. So I thought I would write up various extra ideas here.

I mentioned CPAN::Mini::Inject, but didn't know about CPAN::Inject, which works with a full CPAN mirror instead of a CPAN::Mini mirror. I also didn't know about CPAN::Site which does much the same. I don't know which circumstances each works best in.

I mainly focused on ExtUtils::MakeMaker and Module::Install for packaging modules together. I deliberately ignored Module::Build and didn't know about ExtUtils::ModuleMaker.

The DPAN project on CPAN looks like an ambitious approach to solving the issues I covered and much more too. I probably won't look at it until it has more documentation (I'm a bit of a late adopter), but I should keep an eye on it.

I was grateful for the advice of others who have tried the approaches that I mentioned, sometimes following more thoroughly than I have done. If you're breaking out your code base into lots of small CPAN-style modules, you might find judging the appropriate level of granularity awkward. Talk to your colleagues and don't rush to break things apart too early.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Check out http://search.cpan.org/dist/MyCPAN-App-DPAN/ [cpan.org], which allows you to start from nothing, rather than having to have some existing setup. This allows you to curate what modules are in your local repository, in particular meaning that you can easily dictate which version of a distribution you have.

  • Another advantage of using CPAN packagaing standards for code that's not going to CPAN is that it's really easy to create packages for deploying the code on Debian/Ubuntu (and presumably RPM-based distros' too - I don't know). The dh-make-perl utility takes a CPAN tarball and creates a .deb package.
    • Thanks, that's a good point. I discussed this idea during my talk and like it a lot, but unfortunately you wouldn't know that from the slides alone.

      I dislike posting slides because they don't capture everything mentioned during a talk, but I post them anyway because I figure they're better than nothing.

  • ExtUtils::ModuleMaker isn't the same type of thing as ExtUtils::MakeMaker/Module::Install/Module::Build. Instead, it's analogous to Module::Starter and h2xs - it gives you the framework to write your module in. Looked like that needed clarified.
    --
    The new Strawberry Perl for Windows has been released! Check http://strawberryperl.com for it.