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 name change alleviates my main concern, for whatever that's worth.
I will have to look into to simplifying the dependency chain of Test-YAML-Meta.
Re:Interesting..
barbie on 2008-01-10T09:34:55
In fact following your naming, it may be appropriate to change the name of my distribution to Test-CPAN-Meta.
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 be written in the YAML format. This means one can easily create correct meaningful META.yml which cannot be parsed by YAML::Tiny, see the still unanswered RT ticket. This is just one problem, others are probably there.
So what to do? We could change the META.yml specification and explicitely allow only the YAML-Tiny format (which needs to be specified, see above). I think this would not be the worst move. The full YAML spec is really huge and it is probably unnecessary to support all of the spec in this case.
Or we can just put the whole of YAML::Syck or YAML into the perl core. After all, it is not that huge (maybe 1% of the current size of the perl core), and having YAML in the core would not be too bad. I don't consider having the syck library in the core to be a problem, unless there are some licensing issues.
Re:Not enough!
Aristotle on 2008-01-10T15:44:29
Writing a spec for the format supported by YAML::Tiny seems like a sound idea, actually. Restricting
META.ymlto 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.Re:Not enough!
Alias on 2008-01-11T08:43:34
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.
