Toolchain Roadmap

From Perl QA
Revision as of 03:53, 20 October 2011 by Sjn (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page is intended to collect and organize plans for improving the Perl toolchain (e.g., CPANPLUS, ExtUtils::MakeMaker, Module::Build, Module::Install, etc.). Generally, the roadmap should focus on work that establishes or changes standards or that impacts interoperability between toolchain components.

There are two sections: "Enhancement proposals" for summaries of proposed global changes; and "Work to be done" for module-specific enhancements or major bug fixes.


Enhancement proposals

Generally accepted as needed


The MYMETA.yml proposal is for Makefile.PL and Build.PL to create a MYMETA.yml file, following the META.yml spec, that will include the results of any dynamic configuration (e.g. OS specific dependencies). This will replace PREREQ_PM parsing from Makefile or _build/prereqs parsing as the means for toolchain modules to read determine post-configuration dependencies.


  • -- support has been added (and will be in 5.10.1, no less)
  • CPANPLUS -- not yet supported
  • Module::Build -- support exists in a branch not yet merged to trunk
  • Module::Install -- ADAMK is working on adding support
  • ExtUtils::MakeMaker -- not yet supported. Should use data from BUILD_REQUIRES.

Proposed or still under debate

Quiet and simple auto-configuration

First-time configuration of has a blizzard of configuration options. Even autoconfig generates screenfulls of output. This could be much more user friendly. First, if autoconfig is run, output should be hidden. Seconds, a URL should either be autoconfigured somehow or else the config for that should be run automatically, not as a second configuration after auto configuration.

Add local::lib support to CPAN/CPANPLUS

It would be great if CPAN/CPANPLUS had smarter/automatic support for local::lib to make local installations easy. Imagine on a fresh vendor perl 5.10.X, being able to run a command like this:

   $ perl -MCPAN -e shell
   cpan> o conf local_lib

and have everything autoconfigured for local::lib.

Upgrading should upgrade Module::Build and ExtUtils::MakeMaker

Upgrading either installer should force an upgrade to a sufficiently recent M::B or EU::MM. In the case of CPANPLUS, it should probably be done via CPANPLUS::Dist::Build prerequisites. For, where M::B is optional, the prerequisite should only be added if M::B is already installed. (I.e. it should only upgrade, but shouldn't force the issue.)


Both and CPANPLUS have similar but slightly different code for interacting with Makefile.PL and Build.PL and the subsequent build/make targets. The code could be refactored into a single, common dependency that provides an interface that hides the details of running *.PL in a subprocess and returning results, prerequisites, etc.

Minimum META.yml requirement

EWILHELM described on perl-qa and module-build how there's no way to get a META.yml reader to know that it must upgrade itself to deal with a newer META.yml spec. Analogous to 'configure_requires', if this capability is added to tools and/or the spec itself now, then we enable "forward-compatibility" as META.yml evolves. This could be having CPAN/CPANPLUS know what spec version they understand and try to upgrade themselves if they see a future spec or see a higher 'meta-yml-required' key.

META.yml spec changes

There are numerous deficiencies with the current spec. See CPAN Meta Spec Proposals for specific ideas for improvement.


Switch from YAML to JSON as the preferred format for META files. Means that we need or equivalent in core.

Work to be done

After 1.94:

  • Merge MYMETA.yml support
  • Deprecate "prefer_installer" and have preferred installer default to Module::Build. (Possibly add a new "override_installer" option for those who really need to force Makefile.PL over Build.PL)
  • Add support for 'recommends' and 'conflicts' prerequisites (This is more problematic, and should not be implemented until the implications of this are fully solved)


  • Add support for reading MYMETA.yml


  • Add ability to capture Build.PL, Build and Build test output


  • Add support for MYMETA.yml creation


After 0.34:

  • Add support for MYMETA.yml creation (done)


  • Add support for MYMETA.yml creation (done)
  • Agree with ExtUtils::MakeMaker on an equivalent to NO_META.


YAML::Tiny is used at least by Module::Build and Module::Install to create META.yml.

Personal tools