On 9 October 2015 at 18:04, Chris Barker <chris.bar...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
