All the Perl that's Practical to Extract and Report

Testing META.yml upgrades

barbie on 2008-03-18T13:26:30

Following an email about missing licences in Test-CPAN-Meta, I reviewed the spec and realised I'd made a slight error. The spec suggests some of the valid licences out there, but the text for the field 'license' need only contain a string. It doesn't have to be a known licence. As such I tidied up the code a bit and while I was at it, add some functionality that Adam asked me for a couple of months ago.

So yesterday I fixed up both Test-CPAN-Meta and Test-YAML-Meta to include the following:

  • the 'license' field only requires a string,
  • the licence validating code now returns 1 for a known licence, 2 for an unknown licence and 0 for fail,
  • meta_yaml_ok() and meta_spec_ok() now return the loaded hashref, if you need it.

Regards the latter, Adam wanted to specifically check that a value in the hash was there. Previously there were no additional tests he could perform without loading the file himself. So now it's there if you need it.

Thanks.

Bernhard on 2008-03-18T15:16:24

I'll test this with tonights release of Parrot 0.6.0.

Regards, Bernhard

differences?

rjbs on 2008-03-18T22:26:34

Is the only difference between these two modules the tool used to parse the YAML content of the file? Having an explanation of that in the POD would be really helpful. I spent a bit of time squinting at the two of them.

Re:differences?

barbie on 2008-03-19T00:19:41

Yes, and Yes :)

Test-CPAN-Meta came about due to Adam creating the Parse-CPAN-Meta distribution, which is planned for core status. As such TCM wouldn't need any non-core modules. Originally I was going to let Test-YAML-Meta disappear, but have changed my mind in the event someone wants to specifically use a YAML parser to validate.

any license is valid?

rjbs on 2008-03-18T22:29:48

The "license" entry in META.yml has long stymied me. The spec says: "See the Module::Build manpage for the list of valid options." Unfortunately the link to the manpage is busted.

Module::Build::API seems to provide this list, though. The wording of the specification is vague, but given that there is a list of valid options, isn't anything else invalid?

Re:any license is valid?

rjbs on 2008-03-18T22:32:49

...furthermore! The list from Module::Build::API is unclear. "apache" isn't qualified, so it's not clear if it means 1.0, 1.1, or 2.0. GPL and LGPL are also not versioned, but Artistic is.

Ugh.

copyright:
  license:  Software::License::Artistic_2_0
  year: 2008
  holder: Ricardo Signes
Or something, please.

Re:any license is valid?

barbie on 2008-03-19T00:35:41

The spec does say look at that link for a list of valid options, but itself only implies that it is required and a string. However, M::B::API states "Valid options include:", thus I've taken that to mean that this is not an finite list, but a starting point. In the resources section there is the ability to list the licence URL, which could be updated from anything listed in M::B::API or my modules. I consider the ones I list internally to be an example rather than set in stone.

Unfortunately the discussion regarding the META.yml spec still seems to be stuck on the M::B list, which I personally have no interest in joining. I would prefer to see the spec to be completely independent from any other distribution, thus making it much easier to submit patches, instead of them getting hidden in a RT queue for something else.