NEILB's Blog

Last week I attended the toolchain summit in Lyon, along with 38 other members of our community. For four days we were all working to make the CPAN and Perl toolchain better. This is my log of what I did.

A couple of times recently I've had to deal with distributions that have both a Build.PL and Makefile.PL. I've never been sure of the right way to handle such dists, and in both of the recent times I ended up with problems. From talking to various people on IRC and elsewhere, it seems like there's no good reason to have both. Personally I go with Makefile.PL (with ExtUtils::MakeMaker) if it's someone else's dist, or Dist::Zilla if it's a full adoption.

There are quite a few CPAN dists on github that don't have the repo listed in the metadata. This post shows how to fix that for a dist that uses Module::Install. I hit various problems, so I'm writing down these notes for next time, and so that people can correct anything I got wrong.

I've been asked a few times why the PR challenge only supports github, and not other repo sites. There are two main reasons: (1) it's by far the most popular, and (2) I have various scripts which use the GitHub API, and I'm too lazy to look into dealing with the other sites. Here are the stats to back up the first point.

As I've previously written about, one of the things I do when I adopt a distribution is to get it 'CPANTS clean'. To make my life ever-so-slightly-easier, I've created a Dist::Zilla command that will generate the CPANTS Kwalitee score for your distribution: dzil kwalitee.

Whenever I adopt a module now, one of the first things I do is switch to Dist::Zilla, because it makes my life easier. But now I'm thinking I should only do this when it's a clear adoption, with minimal chance of the previous maintainer getting involved again. There's the perennial problem people have with DZ: to work on a module you have to install Dist::Zilla, and that doesn't always go smoothly.