Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why META.yml is not (currently) YAML (or JSON) 12 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Well, now we have something for people to debate over beers in Birmingham.

    In seriousness -- since we're about at the point where toolchain hackers are going to unleash MYMETA.yml on the world, maybe we should take a collective deep breath and decide if that's in fact what we want.

    There are benefits to re-using the META.yml spec and format. (In part, it makes MYMETA.yml easy to implement -- I added support for it to CPAN.pm in about 3 lines of code.) On the other hand, maybe it makes sense to implement MYM

    • > Where should people's marginal effort go?

      To start with, it should go towards finding a consensus.

      People doing things their own way, and have that ultimately become the default way (locking in any defects as 'official') is what gets us into half our messes in the first place.

      • Clarification: I don't mean to suggest we should do design by committee, but that at the point when people's self-driven new ideas reach the point at which said person starts to suggest that everyone should adopt them, we put those ideas in front of the inquisition and pick out the bugs.

  • PAUSE started to parse the META.yml files with YAML::XS today to get the ball rolling. The request for the move came from RJBS and I think it's a road worthwhile to explore. One should also link to his blog [manxome.org] in this context.

  • Why not use XML? I guess there's not enough glory: it already exists and works!

    • The key limiting factor is that whatever we use, we need support in the Perl core.

      • No, we don't. We only need something capable of parsing these meta files before we install non-core modules.

        All the core really needs is a way to bootstrap the process of installing other modules, distributions, or bundles.

        • This is a simple dependency chain.

          1. All the core really needs is a way to bootstrap the process of installing other modules, distributions, or bundles.

          Correct. Thus...

          2. To bootstrap the installation of other modules, you need a new enough toolchain.

          3. To be able to get a new enough toolchain, you need configure_requires (that was the entire point of having it)

          4. To determine configure_requires, you need to be able to read META.yml

          Therefore...

          5. You need a way to read META.yml in the core.

          The particular fo

          • You need a way to read META.yml in the core.

            If that were true, no installation of a Perl version which lacks this reader in the core would be able to install Perl modules which require the reader. As that's obviously not the case....

            Alternate solution: make the first thing a pristine, freshly configured, built-from source Perl distribution downloads when you want to install something a single bundle which contains just enough hand-selected code to allow upgrading the installation process. Do this throug

            • If that were true, no installation of a Perl version which lacks this reader in the core would be able to install Perl modules which require the reader.

              This is pretty much exactly what happens when you take a fresh Perl 5.8.8 install and try to install anything that needs Module::Build.

            • I should also note you COULD take the path you suggest.

              But then none of those extra modules you need during FirstTime-time would themselves be allowed to use any new toolchain modules.

              Which is technically a valid solution, but would require everyone involved in the toolchain to agree on a fixed back-compat set of core toolchain modules they would restrict themselves to.

              The alternative (putting it in the core) allows all those modules to be upgraded as well and doesn't create a two-class system.

    • Both JSON and XML are well established, fully specced and popular formats (XML more so, but there is a lot of JSON out there too). Picking one over the other should be based on a couple of key points where I think JSON far outshines XML:

      1) Like Alias said, which ever we pick needs to make it's way into the Core. For XML if we we'd need to pick a subset since a full XML parser is big and complicated. JSON in comparison is easy and simple. A JSON parser would be small and stand a better chance of making it in

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.