Bug #52685 for Test-YAML-Meta: optional_features with upper-case key

Fri Dec 11 15:25:45 2009 user42 [...] zip.com.au - Ticket created

Subject:	optional_features with upper-case key
Date:	Sat, 12 Dec 2009 07:24:42 +1100
To:	bug-Test-YAML-Meta [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

With Test::YAML::Meta 0.13 and recent debian i386 perl 5.10.1, checking the META.yml below perl -MTest::YAML::Meta -e 'meta_yaml_ok()' gives # ERR: Missing mandatory field, 'abstract' (abstract) [Validation: 1.4] # ERR: Key 'source_FQ' is not a legal keyword. (optional_features -> source_FQ) [Validation: 1.4] where I hopped upper-case in the feature name would be accepted. The spec seems to be silent on what feature names should look like, so you'd presume anything is fine. Though I suppose non-ascii or unprintables would be asking for trouble! Upper case is pretty likely in an abbreviation (which is how I struck it), so you'd hope that it would be allowed if nothing else.

--- #YAML:1.0 name: foo version: 1 generated_by: hand license: gpl author: - Me <me@me-me-me.org> meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.4.html version: 1.4 optional_features: source_FQ: description: Something needing Finance::Quote. requires: Finance::Quote: 0

Sat Dec 12 03:59:56 2009 BARBIE [...] cpan.org - Correspondence added

Although not explicitly stated in the current specifications (v1.0 - v1.4), the convention has been to precede user defined keys with "[xX]_". However, the three META.yml test distributions have so far omitted this. I have now updated all three to accept user defined keys, as defined in the current blead version of v2.0 of the specification: http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod#structure Fixed in: Test-CPAN-Meta-0.15 Test-JSON-Meta-0.03 Test-YAML-Meta-0.14

Sat Dec 12 03:59:57 2009 The RT System itself - Status changed from 'new' to 'open'

Sat Dec 12 03:59:57 2009 BARBIE [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Dec 12 17:35:18 2009 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #52685] optional_features with upper-case key
Date:	Sun, 13 Dec 2009 09:34:55 +1100
To:	bug-Test-YAML-Meta [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"Barbie via RT" <bug-Test-YAML-Meta@rt.cpan.org> writes: Show quoted text

> > Although not explicitly stated in the current specifications (v1.0 - > v1.4), the convention has been to precede user defined keys with > "[xX]_".

That doesn't sound right for the optional features names. The effect would be that anything is allowed in lower case, but if you want upper case you must write x_. That x_ bit is for extensions to maps with spec-defined keys isn't it? In the optional features names there isn't anything spec-defined, it's all user-defined names, and you're free to write anything, isn't it? Either way it would help for the spec to say something there, as I can't imagine I'll be the last to wonder what it is or isn't supposed to be. Show quoted text

> as defined in the current blead version of v2.0 of the specification:

Sounds a bit dangerous to enforce future spec against META.yml's which only declare themselves as 1.4 or whatever. But my reading of that x_ would be that in 1.4 no unknown keys are allowed (toplevel, requires maps, etc), but 2.0 allows unknown keys if they begin x_, ie. a loosening ...

Sat Dec 12 17:35:19 2009 The RT System itself - Status changed from 'resolved' to 'open'

Fri Dec 18 14:15:15 2009 BARBIE [...] cpan.org - Correspondence added

An optional_features keyword is now accepted as a string matching the regex qr/^[a-z][a-z_]+$/i. This will be clarified in meta-spec-2.0. Fixed in: Test-CPAN-Meta-0.16 Test-JSON-Meta-0.04 Test-YAML-Meta-0.15

Fri Dec 18 14:15:22 2009 BARBIE [...] cpan.org - Status changed from 'open' to 'resolved'

Sun Dec 20 20:03:19 2009 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #52685] optional_features with upper-case key
Date:	Mon, 21 Dec 2009 12:02:42 +1100
To:	bug-Test-YAML-Meta [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"Barbie via RT" <bug-Test-YAML-Meta@rt.cpan.org> writes: Show quoted text

> > qr/^[a-z][a-z_]+$/i

Sounds likely. Is there a reason to disallow digits? Someone will want "support_rss20" or something one day. Digits would make it a perl symbol/word thingie more or less.

Sun Dec 20 20:03:20 2009 The RT System itself - Status changed from 'resolved' to 'open'

Wed Dec 23 08:44:30 2009 BARBIE [...] cpan.org - Correspondence added

Show quoted text

> Is there a reason to disallow digits? Someone will want > "support_rss20" or something one day. Digits would make it a perl > symbol/word thingie more or less.

It was a decision taken by the meta-spec maintainer. If this pattern should change, then it will be reflected in a future release of the distributions.

Wed Dec 23 08:44:31 2009 BARBIE [...] cpan.org - Status changed from 'open' to 'resolved'