On Jul 16, 2013, at 9:40 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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. So to be clear, this means it's { "requires": [ "foo", "bar" ] } ? And it means that having multiple combinations of the same extra/envs is disallowed so I'm going to have to collapse everything back down since it's not stored that way at all? > > * 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 | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
