manylinux tags should come after linux tags

[dholth]

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]

There's disagreement over whether this should occur in the pip issue tracker at https://github.com/pypa/pip/issues/6523, so this is on hold until that's resolved.

[xavfernandez]

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 https://github.com/pypa/pip/pull/6565#issuecomment-498188384)

[brettcannon]

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

[xavfernandez]

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]

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

[dstufft]

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

[pradyunsg]

Closing in favor of #239 then. :)

[henryiii]

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]

I've reopened the issue.

[brettcannon]

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.