[Distutils] PEP 426 updated based on last round of discussion
Nick Coghlan
ncoghlan at gmail.com
Tue Jul 16 15:40:12 CEST 2013
I actually pushed this to python.org on the weekend but forgot to
announce it on the list.
The latest version of PEP 426 is up at http://www.python.org/dev/peps/pep-0426/
It was a net deletion of content despite going into more depth in a
few areas, so I'm counting that as a win for clarity :)
Change details are at http://hg.python.org/peps/rev/067d3c3c1351
Significant changes:
* serialisation prefix changed to "pydist". This metadata is the
metadata that exists at the sdist level. Wheels and installation may
add other metadata files, and PyPI will publish additional metadata
extracted from the archive contents, so I decided "pymeta" didn't feel
write (the name of the schema file changed as well, but I did that in
a separate commit so the diff stayed readable)
* all the *_may_require fields are gone (as previously discussed)
* rather than "install specifiers" I went with "requirement
specifiers" (install turned out not to read very well)
* accordingly, the subfields of dependency specifiers are "requires",
"extra" and "environment"
* the abbreviated form (which has "requires" as a list) was easy
enough to specify, so that's what I used. The unpacked form (where
multiple entries in the same dependency list have the same
extra/environment combination) is explicitly disallowed in order to
encourage consistent formatting.
* clarified that internal whitespace is permitted in requirement
specifiers (there may be a simpler way to specify this, such as "all
whitespace in requirement specifiers is ignored")
* I made the change to explicitly distrust "Provides" data retrieved
from a public index server, and noted that projects defining a virtual
dependency should claim that name to define the default provider.
* noted that Debian packagers may want to map extras to Recommended or
Suggested packages
* noted some possible use cases for metadata extensions
* fixed and clarified various things in the reference copy of the JSON
schema (it could still do with an audit against the current PEP text,
though)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list