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. Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
