On Sep 18, 2018, at 8:44 AM, Olivier Grisel <olivier.grisel@ensta.org> wrote:
That's an interesting proposition.
Would pip be able to automatically select the most recent compatible wheel when two are available on PyPI?
Yes. Well “recent” isn’t the right way to describe it. Basically when pip is looking through the list of wheels for a given version that are all compatible with the current platform, it tried to select the most “specific” wheel for that platform (with the idea that the more specific the wheel is, the more likely it is to work and be performant etc). For the hypothetical of manylinux1, manylinux2010, manylinux2016, and manylinux2020, for a system that supported all of those, I don’t see any reason why we wouldn’t consider manylinux2020 to be more specific than manylinux2016, which is again more specific than 2010, and 1. One nice side effect of this case, is if we ever enable something like an “ubuntu X.Y” wheel, that it doesn’t mean that a project would have to target every possibly platform. They could do something like publish a manylinux wheel to cover a wide range of linux, but if a significant number of their users is on ubuntu 18.04, they could *also* publish an ubuntu_18_4 wheel that would take precedence. This even works correctly for pure Python fallbacks, for instance, if you have a C module that speeds up a pure Python module, you could publish a pure python wheel, and then compiled wheels for whatever platforms you targeted, and pip would prefer the wheel with compiled code over the pure python one.