[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Paul Moore]

On 9 October 2015 at 18:04, Chris Barker <chris.barker at noaa.gov> wrote:
> Which seems to point more to having an optional "binary_build" component to
> the name. Not sure what syntax is available, but the idea would be that:
>
> "numpy|mkl"
>
> and
>
> "numpy|openblas"
>
> would both match "numpy"
>
> which, of course would require changes to the whole stack...

This sounds more like it's an extension of the wheel "compatibility
tag" approach. That's another option I can imagine being worth looking
at.

Basically, wheels currently encode in their names the Python version,
ABI and architecture(s) they work on. That's sufficient for simple
uses, but for more complicated scenarios you need more (such as, "this
wheel is only valid if library FOO is present). It's not impossible to
extend the compatibility tag mechanism to include such things, but
there are a number of issues that would need to be thrashed out (spot
the common theme here? :-)) Specifically, it's horribly cumbersome to
encode everything in the filename, so some more scalable mechanism is
needed. Also, you need a notion of compatibility order (is wheel X
"more compatible" with your system than wheel Y?). And of course,
compatibility is about "does it work with what's there?" which doesn't
allow for the possibility of downloading and installing a dependency
(that's what dependency resolution does, compatibility checking is at
a later stage in the process).

So again this is a possible solution, but needs someone to work on the details.


... or thinking again, maybe you mean having multiple packages
(numpy_mkl, numpy_openblas, ...) all of which satisfy a "numpy"
requirement? That's definitely viable, the Metadata 2.0 spec allows
for one package "providing" an implementation of another
(https://www.python.org/dev/peps/pep-0426/#provides). But that part of
Metadata 2.0 isn't implemented yet - it needs some people with time to
work on it again, and it will probably be implemented alongside "sdist
2.0", which is what we've been calling "when we get round to
reworking/rethinking the sdist format".

Paul

Paul