Slash Boxes
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 ]

dagolden (6584)

  (email not shown publicly)
AOL IM: xdaveg (Add Buddy, Send Message)

Journal of dagolden (6584)

Wednesday August 26, 2009
06:29 PM

Call for proposals: CPAN META Spec

[ #39539 ]

The CPAN META Spec is the basis for the META.yml metadata files included in most modern CPAN distributions. Since the spec was last updated two years ago, there have been suggestions in many forums for how it could be improved in clarity or functionality, but nothing has been done.

To move from ideas to implementation, I have convened a working group of Perl/CPAN toolchain developers, maintainers, packagers and indexers -- the people responsible for the tools you use to configure, build, install or search for CPAN modules -- to review proposals, reach consensus and ultimately implement a new CPAN META Spec.

To ensure that we benefit from the best ideas in the Perl community, on behalf of this working group, I am issuing a public call for proposals.


Here is the process and timeline:

  1. Add proposals to the CPAN Meta Spec Proposals page on the Perl QA Wiki. Discussion and refinement is encouraged through the discussion page on the wiki or on the cpan-workers mailing list (see below for details)
  2. The Call for Proposals will close on Oct. 1, 2009.
  3. The working group will post proposals on the cpan-workers mailing list for public discussion
  4. Public discussion will close on Nov. 1, 2009.
  5. The working group will reach consensus on proposals to adopt or reject and release a new CPAN META Spec no later than Dec. 1, 2009.


Since the work of implementation requires volunteer effort, the working group is looking for incremental improvements rather than complete rewrites of the spec. Proposal are more likely to be adopted if they:

  • Improve clarity or resolve ambiguity
  • Are narrow in scope
  • Address specific, current deficiencies
  • Are consistent with the general style of the existing spec
  • Require minimal implementation effort


The current spec: Browse the current spec, as converted to HTML, here:

The repository: The official spec draft file, META-spec.pod, has been moved from the Module-Build repository into its own repository on github. Please feel free to include proposed patches as part of proposals:

The wiki: Proposals will be kept on the Perl QA Wiki:

The mailing list: Subscribe to cpan-workers by emailing List archives are available at

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One major problem with YAML files [], is support for Unicode, more specifically: different YAML parsers have a different default for assuming a file is in UTF-8, or not.

    Why would we need Unicode? Most of all, to spell people's names correctly.

    My proposal to resolve the issue is to have a default encoding for plain text files, my preference being ISO-Latin-1 (which is, I presume, the default for source code on CPAN, too...?), and that for using Unicode (including UTF-8), it requires a BOM marker [].

    (p.s. I cannot

    • Already there in the "Other brainstorming" section:

      * Make Unicode support explicit (whether allowed or prohibited)

      If someone expands that into a proper proposal, it will be considered.

      To be clear, the proposal process is not a "wishlist" process. The working group is not volunteering to implement every suggestion anyone has.

      Proposals that someone cares enough to write up formally indicate issues that are important enough for someone to invest time in. If it's not important enough for someone to spend ti

      • Isn't YAML 1.1 specified to be utf-8 anyway?

        • The current CPAN META Spec is implemented in YAML 1.0 and few of the existing Perl YAML parsers are 1.1 ready. That's part of the issue.

          -- dagolden

          • Anyway, I will write a proposal to define the META spec in terms of (Perl) data structures, and not anymore in terms of YAML. Though examples could still be in YAML (it's more readable than Perl or JSON or anything else); and there should be an appendix with recommended serialization formats (which would be YAML 1.0/1.1/Tiny/whatever, but probably also a Perl data dump).