Skip to content
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

Open
dholth opened this issue May 17, 2019 · 10 comments
Open

manylinux tags should come after linux tags #160

dholth opened this issue May 17, 2019 · 10 comments

Comments

@dholth
Copy link
Member

dholth commented May 17, 2019

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.

brettcannon added a commit to brettcannon/packaging that referenced this issue Oct 18, 2019
Allows for one to compile a wheel locally to override potentially issues with the manylinux equivalent.

Closes pypa#160
@brettcannon
Copy link
Member

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.

@xavfernandez
Copy link
Member

xavfernandez commented Oct 21, 2019

I think an agreement was found to add a new local/localhost platform tag that would always be considered as the most specific platform.

This would need an update on PEP-425 (or a new one) to make it official though.

(cf pypa/pip#6565 (comment))

@brettcannon
Copy link
Member

@xavfernandez I'm waiting for someone to state that without using the word "I think". 😉

@xavfernandez
Copy link
Member

Well, Daniel seemed to be in favor since he's the author of pypa/pip#6565.
And nobody has objected yet.

It might be interesting to have @dstufft opinion on the local platform tag since he was opposed to the first version.

@pradyunsg
Copy link
Member

IMO, localhost/local tag makes sense. If @dstufft isn't opposed, we should move ahead.

@dstufft
Copy link
Member

dstufft commented Nov 16, 2019

I don't have any problems with some sort of explicit "local" tag.

@pradyunsg
Copy link
Member

Closing in favor of #239 then. :)

@henryiii
Copy link
Contributor

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: next(packaging.tags.sys_tags(), which was used by (at least) scikit-build-core, hatchling, and probably others. Fixing this bug has caused people to complain because they "were producing manylinux" wheels already without auditwheel (in tag only). I would have expected linux tag to be above generalized redistributable tags, and I'd expect if someone built an sdist into a wheel, that would be preferred over a generalized "manylinux" wheel with bundled dependencies.

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, linux should come before many/musl even if #239 was added; the argument was that it supported macOS and Windows too, but on linux there's already a "native/redistributable" distinction due to many/musllinux while those don't have a "redistributiable/non-redistributable" distinction yet. "local" tags could still be first; I'd assume most/all build backends would still produce the linux tag first, and you'd have to opt into or retag for local.

@brettcannon
Copy link
Member

I've reopened the issue.

stefanor added a commit to stefanor/hatch-mypyc that referenced this issue Jun 27, 2024
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
stefanor added a commit to stefanor/hatch-mypyc that referenced this issue Jun 28, 2024
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
@brettcannon
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants