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

tags.cpython_tags returns an incorrect value when run from a 32-bit VS developer prompt on a 64-bit Windows #327

Closed
pfmoore opened this issue Jul 31, 2020 · 7 comments

Comments

@pfmoore
Copy link
Member

pfmoore commented Jul 31, 2020

See pypa/pip#8649.

Basically, cpython_tags is using distutils.get_platform here. It should probably be using get_host_platform - as far as I can tell the only difference is for cross-compilation, and (even if we accept that distutils supports cross-compilation, which I'm not sure it does) when installing wheels, we want to use the host platform, not the target platform (as we're not even building, so "target" makes no sense).

@uranusjr
Copy link
Member

uranusjr commented Aug 23, 2020

Quoting @zooba in bpo-38989:

As you say, [get_host_platform and get_platform are] both private functions, and as we investigated adding a "get_target_platform" function, it turned out that nearly all users were expecting the target platform, so rather than updating everything we added one for the less-common case.

So it may be better for packaging.tags to maintain its own platform tag implementation instead of depending on distutils internals.

@altendky
Copy link

Just hit this on GitHub Actions where my 32-bit build for pyqt5-tools was getting 64-bit psutil wheels etc. Would a useful patch be roughly a copy of get_host_platform() minus the cross-build awareness?

@brettcannon
Copy link
Member

@altendky without looking at the code, I simply don't know.

@zooba
Copy link

zooba commented Nov 7, 2020

So it may be better for packaging.tags to maintain its own platform tag implementation instead of depending on distutils internals.

Yes, this.

@uranusjr
Copy link
Member

I think #396 fixed this.

@puetzk
Copy link

puetzk commented Apr 26, 2021

Confirmed, it now works for me, using python-3.9.4-amd64.exe via a shell launched with "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat" -arch=x86 -host_arch=amd64" (so VSCMD_ARG_TGT_ARCH=x86)

from packaging import tags
[str(x) for x in tags.cpython_tags()]
--- pip install packaging==20.9
+++ pip install git+https:/pypa/packaging@c8008265eac83ebf2c3b3c314a682abd4c101de2
-['cp39-cp39-win32', 'cp39-abi3-win32', 'cp39-none-win32', 'cp38-abi3-win32', 'cp37-abi3-win32', 'cp36-abi3-win32', 'cp35-abi3-win32', 'cp34-abi3-win32', 'cp33-abi3-win32', 'cp32-abi3-win32']
+['cp39-cp39-win_amd64', 'cp39-abi3-win_amd64', 'cp39-none-win_amd64', 'cp38-abi3-win_amd64', 'cp37-abi3-win_amd64', 'cp36-abi3-win_amd64', 'cp35-abi3-win_amd64', 'cp34-abi3-win_amd64', 'cp33-abi3-win_amd64', 'cp32-abi3-win_amd64']

@brettcannon
Copy link
Member

Thanks for the confirmations! Closing as fixed.

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