pip: use universal wheels only if there are no others#525
pip: use universal wheels only if there are no others#525allisonkarlitskaya wants to merge 1 commit intoflatpak:masterfrom
Conversation
If any wheel is universal (like py3-linux-any), we'll immediately short-circuit and take it in preference to a source package under the theory that it's probably all pure Python sourcecode in there anyway. This misses an important point, however: some packages (like websockets) have optimized arch-specific wheels with specific optimizations and also publish slower universal wheels as a fallback. Selecting the universal wheel in this case is probably a mistake. Modify the check so we only take the universal wheel if there's no platform-specific one. What happens next is up to user preference: by default you'll end up building from the sdist, but you can also `--prefer-wheels` (possibly with `--wheel-arches`) to get the platform-specific wheels instead.
|
Probably @bbhtt wants to look at this (after a bunch of related work just landed)... |
|
I'd rather have this behind an argument --force-platform-wheels or --force-sdist or such. Universal wheels are better for compat and I don't think it is common to have optimised platform specific wheels. Currently it will force people to use --prefer-wheels more often which is a bit annoying. |
|
Can you point me at examples of projects that have both universal wheels and also platform specific ones for which the platform-specific versions don't offer some benefit (like improved performance)? The very very fact that someone went to the trouble of having such an arrangement sort of suggests to me that there was a point in doing so, but I'm coming at this from the perspective in which I first encountered the issue and maybe there are others that I'm missing... |
|
fwiw, I agree with your comments about universal wheels being "better for compat", which I interpret as "easier". Building an sdist is often a fraught process and it's not unlikely that it involves a build backend or compiler or some other tooling that won't be present in the chosen SDK... I did hesitate in proposing this because I feel like some people will get burned by this when their working builds suddenly stop working because some piece of tooling is missing... But I'm still curious about your comments about the benefits of platform specific wheels (for the cases where they exist)... |
I wouldn't know that without looking into every project individually and also things like this would depend on case by case basis if that code path is being used etc or if it matters in usage. But having none-any and platform specific wheels is common enough. Quickly scanning the top 500 modules on PyPI gives 937 matches. |
2 participants
If any wheel is universal (like py3-linux-any), we'll immediately short-circuit and take it in preference to a source package under the theory that it's probably all pure Python sourcecode in there anyway. This misses an important point, however: some packages (like websockets) have optimized arch-specific wheels with specific optimizations and also publish slower universal wheels as a fallback. Selecting the universal wheel in this case is probably a mistake.
Modify the check so we only take the universal wheel if there's no platform-specific one. What happens next is up to user preference: by default you'll end up building from the sdist, but you can also
--prefer-wheels(possibly with--wheel-arches) to get the platform-specific wheels instead.