6.4.0: invalid choice: 'linux_x86_64'

[debug-richard]

With version 6.4.0 of auditwheel the using the platform linux_x86_64 does not work.

auditwheel repair: error: argument --plat: invalid choice: 'linux_x86_64' (choose from 'manylinux_2_39_x86_64', 'manylinux_2_38_x86_64', 'manylinux_2_37_x86_64', 'manylinux_2_36_x86_64', 'manylinux_2_35_x86_64', 'manylinux_2_34_x86_64', 'manylinux_2_31_x86_64', 'manylinux_2_28_x86_64', 'manylinux_2_27_x86_64', 'manylinux_2_24_x86_64', 'manylinux_2_17_x86_64', 'manylinux_2_12_x86_64', 'manylinux_2_5_x86_64', 'manylinux2014_x86_64', 'manylinux2010_x86_64', 'manylinux1_x86_64', 'auto')

I can not find anything in the changelog or code changes about this, is this a regression?

[mayeut]

If this was possible with previous versions then it's a regression (most likely introduced in detect architecture/libc from wheel).
I have absolutely no idea what it was doing in that case as it's not something tested (hence the regression).
Will dig more at the end of the week.

[mayeut]

Using --plat linux_x86_64 with 6.3.0 was doing something but what it was doing is not useful at all, it ends up grafting glibc which is not good at all.
I'd consider that it was a bug it was allowed in the first place given it seems to only output invalid wheels.

@debug-richard, what was the use case, am I missing something ?

[fidothe]

I have this issue too. My company's use case is that we want to enable local installation of our wheel by our developers on their machines. We have a python extension package that uses Cython to provide an API wrapper around a couple of shared libraries we also develop. Without auditwheel, we cannot install the development version of the package: doing so breaks the link between the Cython extension module and the shared libraries it wraps. There are some tasks we want to locally install the package for – it's used as part of a larger test suite driver. I don't believe we can use editable installs for this.

We effectively want to be able to run auditwheel to do the bundling, but not change the platform tag, in those cases. We use auditwheel in conjunction with a manylinux container to build release versions of the package, but constraining developers to a manylinux container isn't really a viable option.

[mayeut]

Thanks for the use case @fidothe
Doesn't the auto mode work in your use-case (this might depend on the distros uses by the developers) ?
I'd rather not reintroduce bundling of the glibc and it might be a bit cumbersome to introduce a new mode if auto works.