[Distutils] Handling the binary dependency management problem

Oscar Benjamin oscar.j.benjamin at gmail.com
Tue Dec 3 16:30:53 CET 2013


On 3 December 2013 13:53, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 3 December 2013 22:49, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
>
> Hmm, I likely wouldn't build it into the core requirement system (that
> all operates at the distribution level), but the latest metadata
> updates split out a bunch of the optional stuff to extensions (see
> https://bitbucket.org/pypa/pypi-metadata-formats/src/default/standard-metadata-extensions.rst).
> What we're really after at this point is the ability to *detect*
> conflicts if somebody tries to install incompatible builds into the
> same virtual environment (e.g. you installed from custom index server
> originally, but later you forget and install from PyPI).
>
> So perhaps we could have a "python.expects" extension, where we can
> assert certain things about the metadata of other distributions in the
> environment. So, say that numpy were to define a custom extension
> where they can define the exported binary interfaces:
>
>     "extensions": {
>         "numpy.compatibility": {
>             "api_version": 1,
>             "fortran_abi": "openblas-g77"
>         }
>     }
[snip]
>
> I like the general idea of being able to detect conflicts through the
> published metadata, but would like to use the extension mechanism to
> avoid name conflicts.

Helping to prevent borken installs in this way would definitely be an
improvement. It would be a real shame though if PyPI would contain all
the metadata needed to match up compatible binary wheels but pip would
only use it to show error messages rather than to actually locate the
wheel that the user wants.


Oscar


More information about the Distutils-SIG mailing list