[Distutils] PEP 426 updated based on last round of discussion

[Donald Stufft]

On Jul 16, 2013, at 9:40 AM, Nick Coghlan <ncoghlan at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130716/bc75b58e/attachment-0001.pgp>