support repair to lowest support manylinux tags

[trim21]

currently users will need to call auditwheel show and auditwhell repair --platform=... to change tag to support version. hope it's possible to repair wheel recommand tags showed in auditwheel show, with --platform=auto maybe. or privede a json output that can be readed by machine to make it doable by simple python script.

[mayeut]

I'm not sure exactly what you're suggesting with --platform=auto so I'll try to guess, please correct me.

The current default is manylinux1.
Your trying to build on a system with a newer glibc (not using a manylinux image which overrides the default via environment variable) and you'd like for the default to be whatever version of glibc you're running ?
Am I getting this correctly ?

PS: by default, auditwheel will "dual" tag to the requested platform and the lowest compatible tag. You can optionally disable the lowest compatible tag.

[trim21]

Am I getting this correctly ?

yes.

And --platform=auto is a typo, it's actually --plat=auto.

for example, I have a hatch project generate wheel with name dist/package-0.1.1a0-cp311-cp311-manylinux_2_31_x86_64.whl, and auditwhell show will output this:

This constrains the platform tag to "manylinux_2_17_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

--plat=auto will use manylinux_2_17_x86_64 as tag, repair wheel tag from manylinux_2_31_x86_64 to manylinux_2_17_x86_64 automatically.

and as for why I didn't use manylinux containers, I have some project need c++ 20 and gcc 13...

[mayeut]

I was not referring to the typo ;-)

ok so this seems like a bug/feature with hatch in the first place then.
you can still re-repair it with auditwheel (as you're trying to do).

I'm clearly not comfortable with simple retags like that & that's why the dual tag exists which would rename your wheel manylinux_2_17_x86_64.manylinux_2_31_x86_64. The dual tag, IMHO, while adding extra length to the filename, convey some semantic. "I was built & tested on 2.31, I still work on 2.17 but that might change in the future even without a change in build environment".

Either you know you want to explicetly support some older glibc version, in which case, you can use that for --plat=manylinux_2_17_x86_64 or it's best effort but no guarantees in which case, the dual tag is appropriate.

I think that changing the default of auditwheel to detect the currently running version of glibc would be a sane default and would be enough for you to get a dual tag wheel.

in the meantime, maybe using --plat=manylinux_$(ldd --version | head -1 | awk '{ print $NF }' | tr '.' '_')_$(uname -m) would work without worrying to much about what version of glibc you're running (if it's a known policy, which it should for Ubuntu LTS versions - except noble / 24.04)

[trim21]

ok so this seems like a bug/feature with hatch in the first place the

not really....

I have some other project use setuptools directly and it just tag wheel as linux, that's the real reason I need auditwheel...

changing the default of auditwheel to detect

I'm not proposing to change default behavoir of auditwheel, just add new behavoir.

[mayeut]

not really....

Well, if hatch is tagging manylinux wheel (i.e. not linux ones) as the name of you're output suggests dist/package-0.1.1a0-cp311-cp311-manylinux_2_31_x86_64.whl, either it calls auditwheel with a flag that specifically tells auditwheel not to dual tag or it has some custom logic. In either case, you were drawn to using auditwheel because hatch does not tag manylinux wheel the way you want it to so it might benefit from a feature request, that's all I'm suggesting (I would not be suggesting anything if it only outputted a linux_x86_64wheel).

I'm not proposing to change default behavoir of auditwheel, just add new behavior.

ok, changing or not the default as another matter, would an auto feature that works like --plat=manylinux_$(ldd --version | head -1 | awk '{ print $NF }' | tr '.' '_')_$(uname -m) would work for you ?

[trim21]

Well, if hatch is tagging manylinux wheel (i.e. not linux ones) as the name of you're output suggests dist/package-0.1.1a0-cp311-cp311-manylinux_2_31_x86_64.whl, either it calls auditwheel with a flag that specifically tells auditwheel not to dual tag or it has some custom logic. In either case, you were drawn to using auditwheel because hatch does not tag manylinux wheel the way you want it to so it might benefit from a feature request, that's all I'm suggesting (I would not be suggesting anything if it only outputted a linux_x86_64wheel).

let's forget hatch, consider a setuptools + pybind11 project generate a wheel package-0.0.1-cp311-cp311-linux_x86_64.whl. I say hatch juse becuase I use a hatch project to write a example.

ok, changing or not the default as another matter, would an auto feature that works like --plat=manylinux_$(ldd --version | head -1 | awk '{ print $NF }' | tr '.' '_')_$(uname -m) would work for you ?

(I guess that's how hatch tag wheel)

they are not same.

for example (setuptools + pybind11 project), on my machine, $(ldd --version | head -1 | awk '{ print $NF }' | tr '.' '_')_$(uname -m) would be 2_31_x86_64, but auditwheel show says it's consistent with the platform tag: "manylinux_2_24_x86_64". I prefer the recommand platform tag from auditwhell show command

[mayeut]

please read the part about dual tags.
passing --plat=manylinux_2_31_x86_64 should/will yield to a repaired wheel named my package-....-manylinux_2_24_x86_64.manylinux_2_31_x86_64.whl

[trim21]

please read the part about dual tags. passing --plat= manylinux_2_31_x86_64 should/will yield to a repaired wheel named my package-....-manylinux_2_24_x86_64.manylinux_2_31_x86_64.whl

OK, thanks, I missed that.

that looks right to me, thanks for you time.

[mayeut]

PS: there was indeed a bug in hatch pypa/hatch#1438

[trim21]

PS: there was indeed a bug in hatch pypa/hatch#1438

I'm actually using hatch with manylinux container, so I didn't run into this bug...