All the Perl that's Practical to Extract and Report

Using CPAN's Toolchain to Improve Your Code

tomhukins on 2009-11-03T20:27:07

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.

dpan

elliot on 2009-11-04T00:15:42

Check out http://search.cpan.org/dist/MyCPAN-App-DPAN/, 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 plus for following standards

grantm on 2009-11-05T19:59:25

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.

Re:Another plus for following standards

tomhukins on 2009-11-09T09:24:09

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

DiamondInTheRough on 2009-11-06T20:10:10

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.

Re:ExtUtils::ModuleMaker

tomhukins on 2009-11-09T09:20:59

Thanks for the clarification: I should have investigated before mentioning it.