[Distutils] Upcoming changes to PEP 426/440

[Nick Coghlan]

Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies was significantly more
painful to work with than I had expected.

Accordingly, I'm making some adjustments to the way dependencies are
defined to bring them more into line with the way the contributors
field and contact metadata works:

1. The "*_may_require" fields are all going away (leaving only the
"*_requires" fields)

2. The "*_requires" fields are becoming lists of "dependency
specifier" mappings rather than strings

3. A dependency specifier is now a mapping with the following fields:

* "install": the installation specifier for the dependency
* "extra": as per the current PEP (for conditional dependencies)
* "environment": as per the current PEP (for conditional dependencies)

4. The "install" subfield is compulsory, the other two are optional
(as now, using either of the latter creates a "conditional
dependency", while dependency declarations with only the "install"
subfield are unconditional)

5. An installation specifier is what PEP 426 currently calls a
dependency specifier: the "name [extras] (constraints)" format. They
will get their own top level section (similar to the existing Extras
and Environment markers sections)

In addition to those changes, I'll also be making a change to the
recommended handling of virtual distributions (again based on Donald's
feedback): integration tools should NEVER look at the "Provides"
listings on a public index server to satisfy unmet dependencies.
Instead, virtual distributions should be defined in such a way that
whoever first invents the specific virtual distribution name registers
it on PyPI, using the dependency metadata to pull in a default
implementation. That's the only way to manage virtual distributions on
a public index server that isn't vulnerable to later hijacking simply
by registering a distribution with that name.

As part of documenting that, I'll probably give the notion of "Virtual
distributions" their own top level section (these are distributions
that don't have any code of their own - they just declare dependencies
on other projects to make them easy to install as a group, or to
define the default provider for a dependency that may be satisfied by
any one of multiple distributions).

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia