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

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Wednesday January 09, 2008
07:33 PM

Parse::CPAN::Meta 0.02 - YAML support in the Perl core

[ #35344 ]

In order to complete phase 1 of the CPAN toolchain auto-upgrade work (which consists of changes to about 5-6 toolchain modules to support configure_requires:) we need the ability to parse META.yml to be available in the Perl core (so that we can guarantee auto-upgrade is working on a default install).

YAML::Tiny is the obvious choice for this, since the other options are a) Very large b) Require third-party C libraries.

But there's been a long-standing concern from the YAML faction (camp? clique? posse?) about YAML::Tiny not being a "real" YAML parser, and their concerns that if something is in the core with a "YAML" label on it, people will preferentially use it instead of a real YAML parser.

The compromise position that everyone seems happy with is to put YAML::Tiny (or enough of it to support parsing META.yml) into the core, but not to CALL it YAML, and to hide the package in a namespace that won't tempt people into using it outside of it's intended scope.

So I've create Parse::CPAN::Meta, which was built in the following manner.

1. Copy YAML::Tiny to Parse::CPAN::Meta and rename the namespaces.

2. Remove the YAML-writing half of the code, and just keep the parser.

3. Remove object-orientation, and just keep the Load and LoadFile functions.

4. Remove the global $errstr variable (to avoid potential threading issues) and return all errors via exceptions.

5. Remove YAML-comparison testing, YAML::Syck-comparison testing and round-trip testing from the test suite, but otherwise keep all the same test, sample files and regression tests.

6. Rewrite the documentation to reflect the new purpose of the code.

Somewhat ironically, this means that Parse::CPAN::Meta is significantly "tinier" and probably also faster than YAML::Tiny (but at the loss of the ability to write YAML, which I consider essential for a minimalist YAML implementation).

My intention is that this module becomes dual-lifed from birth, so that it can synchronize with any improvements or bug fixes in YAML::Tiny.

Any feedback is welcome.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The name change alleviates my main concern, for whatever that's worth.

  • is what I use YAML for, this sounds like a great module for about 90% of my yaml needs.

    I'm converting any config files I need to being yaml, it's just one less thing I have to write (config file parser) and I'm liking it.
  • I will have to look into to simplifying the dependency chain of Test-YAML-Meta [cpan.org].

    • In fact following your naming, it may be appropriate to change the name of my distribution to Test-CPAN-Meta.

  • I am still not satisfied. For me the namespace was never a problem, as it reminded me of another markup language with a tiny counterpart, namely SVG and SVG-Tiny. And as "-" is not a valid character for a module name I found it quite natually that it is replaced by "::".

    What bothers me more is that I don't know what is YAML::Tiny supposed to parse. It is not yet specified. I think there should be a written spec first.

    And then further problems: the META.yml specification clearly says that META.yml should

    • Writing a spec for the format supported by YAML::Tiny seems like a sound idea, actually. Restricting META.yml to that subset of YAML, once written, sounds like a better choice to me than putting libsyck in the core. Dual-life modules are “interesting” enough without throwing XS into the mix.

    • There is a LOT more resistance to having significant third-party C libraries in the core, compared to what I've done.

      As for a YAML-Tiny spec, I'll try to knock something up.