-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
manylinux tags should come after linux tags #160
Comments
Allows for one to compile a wheel locally to override potentially issues with the manylinux equivalent. Closes pypa#160
There's disagreement over whether this should occur in the pip issue tracker at pypa/pip#6523, so this is on hold until that's resolved. |
I think an agreement was found to add a new This would need an update on PEP-425 (or a new one) to make it official though. |
@xavfernandez I'm waiting for someone to state that without using the word "I think". 😉 |
Well, Daniel seemed to be in favor since he's the author of pypa/pip#6565. It might be interesting to have @dstufft opinion on the |
IMO, |
I don't have any problems with some sort of explicit "local" tag. |
Closing in favor of #239 then. :) |
Five years later and the 'local' tag hasn't gone anywhere. There's another impact of this that has hurt several backends: this is wrong if the linux tag isn't "higher" priority than the manylinux tags: The fix for backends is: best_tag = next(
iter(
p
for p in packaging.tags.sys_tags()
if "manylinux" not in p.platform and "muslllinux" not in p.platform
)
) IMO, |
I've reopened the issue. |
pypa/hatch#1438 changed the default tag selection in hatchling: > Linux tag is after many/musl; packaging tools are required to skip > many/musl, see pypa/packaging#160
pypa/hatch#1438 changed the default tag selection in hatchling: > Linux tag is after many/musl; packaging tools are required to skip > many/musl, see pypa/packaging#160
After thinking about this a bit this weekend, I think I'm up for this change happening. I don't think the breakage would be large, and logically it makes sense. |
I designed packaging tags to come in order of "most specific to this machine" to "least specific to this machine". Unfortunately pip has interpreted this as meaning "most specified", putting "manylinux1" before "linux_x86_64", even though any "linux_x86_64" wheels visible to pip should have been compiled on exactly the machine you're in.
When a particular manylinux wheel is broken, you should be able to compile a linux_x86_64 wheel, add it to pip's search path, and pip would prefer the wheel you compiled. With manylinux1 first the option of having a folder of known-good-and-preferred wheels is not available, instead you have to use no-binary or avoid specific packages.
It would also be helpful if a packaging tool could just pick the first tag from the list, instead of skipping all the manylinux tags, when choosing a tag for a new binary wheel.
The text was updated successfully, but these errors were encountered: