martin

In order to quickly install a set of Perl modules for a given task, it is nice to have some kind of meta-package serving no other purpose than pulling in a set of other more specific packages. Traditional ways of doing this with CPAN can be found in the Bundle:: and Task:: namespaces. Recent developments, however, seem to have put meta-package maintainers in a predicament. Technologies are shifting once more. In this article, I explain how I rescued my meta-packages with minimal changes.

Bundles rely on CPAN client's magic to get static lists of modules resolved into individual installation jobs. Tasks are empty modules with all kinds of dependencies that will be handled by regular dependency-resolving mechanisms. This is a more flexible approach as there is a configuration step that can check everything about its environment and possibly adapt to it.

One downside of Task:: based meta-packages is that they need to get updated occasionally in order to upgrade existing modules to their latest versions, as bundles do. Of course, the maintainer can check everything before doing so, and intentionally stay away from new versions he or she doesn't like.

So I am sort of used to look after my Task::Whatever packages from time to time and was rather disappointed when they suddenly broke in strange ways. It turns out that the packaging technology they relied on, namely Module::Install, somehow has fallen into disgrace lately.

Module::Install had been designed to simplify writing installers without sacrificing the ability to cope with difficult conditions, such as outdated pre-installed software. However, it now seems outdated itself.

For one thing, it sometimes relies on an insecure @INC path (containing '.') which is for good reason no longer recommended. To give Module::Install based installers a chance to succeed with a clean @INC path, I prepend these two lines:

use FindBin;
use lib $FindBin::Bin;

before this line:

use inc::Module::Install;

That way, the installer modules included in my package will be found at runtime, now with a path relative to the location of the Makefile.PL script rather than the current working directory.

This was not enough to get me a sane package, however. make distdir would no longer re-generate META.yml and META.json files for me, for example. Sneaking into the source code, I found that ExtUtils::MakeMaker's WriteMakefile is called with a NO_META argument for no good reason.

Moreover, the Module::Install documentation now discourages its use altogether in favour of authoring tools like Dist::Zilla. What a mess.

Thankfully, I found advice in Neil Bowers' very fine article Specifying dependencies for your CPAN distribution. Neil lines out how different ways of installing can be configured with dependency metadata.

I still hesitated to rewrite my meta-packages from scratch as the Module::Installer way of specifying things had led me to build own maintenance tools that would parse and generate Makefile.PL files. My solution was to migrate the packages from Module::Install to plain ExtUtils::MakeMaker, with a little extra boilerplate to keep requires and recommends lines intact. Basically, I just defined own subroutines with those names at the top of the script, like this:

my %requires      = ();
my %recommends    = ();

sub requires ($$) {
    my ($module, $version) = @_;
    $requires{$module} = $version;
}

sub recommends ($$) {
    my ($module, $version) = @_;
    $recommends{$module} = $version;
}

As a result, my Task::Whatever modules and my private maintenance scripts now continue to work with no changes other than modified Makefile.PL boilerplate code and, of course, removal of Module::Install's inc subtree. An example can be found in Task::Devel::Essentials on CPAN.

What I missed most was the all_from directive, which had to be replaced by some more explicit configuration parameters, but this was not a big deal.