FAQ
Those of you who were at Birmingham heard me go on and on about my burning
desire to replace the use of YAML in CPAN dist metadata with JSON. I'd be
happy to review the reasons, but for now I'll take it for granted that we all
know them and agree. That certainly seemed to be the case amongst the crowd at
QA09.

Today I updated my proof of concept (and/or civil disobedience dist)
JSON-Meta-CPAN, which makes all the three common build tools (Module::Build,
Module::Install, and ExtUtils::MakeMaker) optionally produce JSON instead of
YAML. With the new version, dists will not produce a META.yml, but will
*instead* produce a META.json. I have also updated my own build system,
Dist::Zilla, to do the same when asked.

Next steps include:

* update PAUSE to prefer META.json to META.yml if available
* update CPAN.pm to look at (MY)?META.json
* update CPANPLUS.pm to do the same
* update the build tools to generate (MY)?META.json by default
* update the META spec to demand JSON
* declare META.yml a legacy file

I think I can manage the first myself; I was just looking at it, and
extract_readme_and_yaml in mldistwatch looks like the important thing.

I am happy to try to slog through more of the other tasks, but I don't know at
what speed I'll go. Unless there are strenuous objections, however, I plan to
assume that we still more or less agree on this plan, and I'm going to start
leading the way by shipping META.json files.

I look forward to the people's glorious future.

--
rjbs

Search Discussions

  • Ask Bjørn Hansen at May 18, 2009 at 12:40 am
    0) Yay for JSON.

    1) Is it really necessary to use ascii instead of just regular utf-8
    for the JSON output?

    2) The documentation is a little confusing saying "If it can be
    loaded, any META.yml file produced will contain JSON." -- but it looks
    like the code (correctly) makes the output file be META.json when all
    is well.


    - ask
  • Ricardo SIGNES at May 18, 2009 at 12:43 am
    * Ask Bjørn Hansen [2009-05-17T20:39:49]
    1) Is it really necessary to use ascii instead of just regular utf-8 for
    the JSON output?
    I figured that by picking ASCII, tools that were crap at handling UTF-8 would
    not mangle the 8-bit data. I do not mean to be taking a stance on what is
    required.
    2) The documentation is a little confusing saying "If it can be loaded,
    any META.yml file produced will contain JSON." -- but it looks like the
    code (correctly) makes the output file be META.json when all is well.
    Documentation bug. Version 5 and prior put JSON content into META.yml.

    --
    rjbs
  • Michael G Schwern at May 18, 2009 at 12:59 am

    Ricardo SIGNES wrote:
    Those of you who were at Birmingham heard me go on and on about my burning
    desire to replace the use of YAML in CPAN dist metadata with JSON. I'd be
    happy to review the reasons, but for now I'll take it for granted that we all
    know them and agree. That certainly seemed to be the case amongst the crowd at
    QA09.
    I remain the loyal opposition. Not as fiercely as with TAP, since META.json
    is intended more for machines than TAP is and so the benefits do not so
    clearly outweigh the complexity of parsing YAML.

    Today I updated my proof of concept (and/or civil disobedience dist)
    JSON-Meta-CPAN, which makes all the three common build tools (Module::Build,
    Module::Install, and ExtUtils::MakeMaker) optionally produce JSON instead of
    YAML. With the new version, dists will not produce a META.yml, but will
    *instead* produce a META.json. I have also updated my own build system,
    Dist::Zilla, to do the same when asked.
    I'll take a patch to MakeMaker to do that on demand.

    Next steps include:

    * update PAUSE to prefer META.json to META.yml if available
    * update CPAN.pm to look at (MY)?META.json
    * update CPANPLUS.pm to do the same
    * update the build tools to generate (MY)?META.json by default
    * update the META spec to demand JSON
    * declare META.yml a legacy file
    I would prefer to still able to produce META.yml but I understand not wanting
    to saddle parsers with having to deal with two protocols. I suppose there's
    nothing stopping me from spitting out both.


    --
    ...they shared one last kiss that left a bitter yet sweet taste in her
    mouth--kind of like throwing up after eating a junior mint.
    -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
    by Tami Farmer
  • Ricardo SIGNES at May 18, 2009 at 1:17 am
    * Michael G Schwern [2009-05-17T20:59:08]
    Ricardo SIGNES wrote:
    Those of you who were at Birmingham heard me go on and on about my burning
    desire to replace the use of YAML in CPAN dist metadata with JSON. I'd be
    happy to review the reasons, but for now I'll take it for granted that we
    all know them and agree. That certainly seemed to be the case amongst the
    crowd at QA09.
    I remain the loyal opposition. Not as fiercely as with TAP, since META.json
    is intended more for machines than TAP is and so the benefits do not so
    clearly outweigh the complexity of parsing YAML.
    Right now, there is more or less an unspoken mandate that the YAML in META.yml
    must be parseable by YAML::Tiny, meaning it has *no* feature benefits over
    JSON. It's just a little easier for humans to read. Seriously, though, just a
    little, itty-bitty bit. q.v.,

    http://cpansearch.perl.org/src/RJBS/Dist-Zilla-1.091370/META.json

    There is no documented, proven YAML implementation in Perl. I think that
    YAML::XS seems to work pretty well, but requires XS. The port of PyYAML still
    hasn't landed -- which is what you said we'd have any day now when you were
    arguing for YAML in TAP -- in Oslo in early 2008.

    The YAML parser and emitter would need to be in core to support CPAN build and
    install tools.

    Why are you still pushing, even a little, for anyone to *keep* making META.yml
    in the future? Are there arguments that I'm not seeing or appreciating?
    Today I updated my proof of concept (and/or civil disobedience dist)
    JSON-Meta-CPAN, which makes all the three common build tools (Module::Build,
    Module::Install, and ExtUtils::MakeMaker) optionally produce JSON instead of
    YAML. With the new version, dists will not produce a META.yml, but will
    *instead* produce a META.json. I have also updated my own build system,
    Dist::Zilla, to do the same when asked.
    I'll take a patch to MakeMaker to do that on demand.
    Once CPAN, CPANPLUS, and PAUSE support JSON, I hope you will consider a patch
    to do it by default.
    I would prefer to still able to produce META.yml but I understand not wanting
    to saddle parsers with having to deal with two protocols. I suppose there's
    nothing stopping me from spitting out both.
    I don't care if both are produced, as long as the rule is "tools should prefer
    JSON if both are present and your tool can parse JSON." Well, I do care, but
    not very much.

    --
    rjbs
  • Michael G Schwern at May 18, 2009 at 1:36 am

    Ricardo SIGNES wrote:
    I remain the loyal opposition. Not as fiercely as with TAP, since META.json
    is intended more for machines than TAP is and so the benefits do not so
    clearly outweigh the complexity of parsing YAML.
    Right now, there is more or less an unspoken mandate that the YAML in META.yml
    must be parseable by YAML::Tiny, meaning it has *no* feature benefits over
    JSON. It's just a little easier for humans to read. Seriously, though, just a
    little, itty-bitty bit. q.v.,

    http://cpansearch.perl.org/src/RJBS/Dist-Zilla-1.091370/META.json

    There is no documented, proven YAML implementation in Perl. I think that
    YAML::XS seems to work pretty well, but requires XS. The port of PyYAML still
    hasn't landed -- which is what you said we'd have any day now when you were
    arguing for YAML in TAP -- in Oslo in early 2008.

    The YAML parser and emitter would need to be in core to support CPAN build and
    install tools.

    Why are you still pushing, even a little, for anyone to *keep* making META.yml
    in the future? Are there arguments that I'm not seeing or appreciating?
    Accept victory gracefully.


    --
    <Schwern> What we learned was if you get confused, grab someone and swing
    them around a few times
    -- Life's lessons from square dancing
  • David Golden at May 18, 2009 at 2:37 am

    On Sun, May 17, 2009 at 7:36 PM, Ricardo SIGNES wrote:
    * update PAUSE to prefer META.json to META.yml if available
    * update CPAN.pm to look at (MY)?META.json
    * update CPANPLUS.pm to do the same
    * update the build tools to generate (MY)?META.json by default
    * update the META spec to demand JSON
    After watching yet another dogfight in RT and the M::B list about
    META.yml parsing, version objects, etc., I would really, really
    appreciate the following as well:

    * A single "canonical" META.json generator and parser -- that all the
    tools use and that could reasonably be lobbied into the core.
    * Unambiguous META spec for version number formatting
    * Spec validation (separate from parsing so it can use non-core tools)
    * Have PAUSE reject dists with an invalid spec

    -- David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedMay 17, '09 at 11:36p
activeMay 18, '09 at 2:37a
posts7
users4
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase