On Tue, May 28, 2013 at 2:07 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > On Mon, May 27, 2013 at 7:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> After preliminary reviews by Donald and Daniel, I have now pushed the >> first complete draft of the JSON-based metadata 2.0 proposal to >> python.org >> >> PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ >> PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/ >> >> With the rationale and commentary, they're over 3000 lines between >> them, so I'm not attaching them here. >> >> The rationale for many of the changes is at the end of each PEP, along >> with some comments on features that I have either rejected or >> deliberately chosen to defer to the next revision of the metadata (at >> the earliest). >> >> Those with BitBucket accounts may also comment inline on the drafts here: >> >> PEP 426: >> https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a87ba/pep_drafts/pep-0426.txt?at=default >> PEP 440: >> https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a87ba/pep_drafts/pep-0440.txt?at=default > > This is looking fantastic so far--thanks to Nick, Daniel, and Donald > for their continued work on this. For now I just have a handful of > minor notes on the latest draft of PEP 426: > > Typos: > > Under "Essential dependency resolution metadata" the "may_require" and > related metadata keywords are spelled with hyphens instead of > underscores. > > Under "Metabuild system" in the first example I think > "some_test_harness.metabuild_hook" was meant to read > "some_test_harness:metabuild_hook" > > > Under "Development, build and deployment dependencies": "allow" -> "allows" > > Under "Support for metabuild hooks": "by allows projects" -> "by > allowing projects" > > Comment: > > I'm not sure if this PEP is the best place for this, but I wonder if > the description of the "Keywords" format could provide some > clarification on how that field should be formatted in older metadata > versions (specifically when including version 1.x metadata for > backwards compatibility). In the past its format has never been > specified. Some tools treat it as a space-separated fields. Others > have treated it as a comma-separated field. Sometimes one or the > other depending on whether commas are present. It's a very annoying > field.
I suggest treating it as a space-separated field for converting from 2.0 to 1.0. To convert from 1.0 to 2.0 you should just split on "not a letter" or if you are feeling ambitious "not some larger set of characters, probably resembling the identifier or package name rules". _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
