This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Same userbase for 32bit and 64bit install on Windows causing conflicts
Type: Stage: resolved
Components: Windows Versions: Python 3.9
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Relocate user site packages on Windows 32-bit
View: 41627
Assigned To: Nosy List: eryksun, lazka, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2021-02-10 20:05 by lazka, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg386804 - (view) Author: Christoph Reiter (lazka) * Date: 2021-02-10 20:05
I'm sure this is already filed somewhere, but I couldn't find anything.

Currently when installing packages with pip using a 64bit Python to --user and then starting a 32bit Python things fail because they look up packages from the same location:

.\python.exe -m site --user-base
C:\Users\user\AppData\Roaming\Python

For example trying to import numpy from a 32bit Python when it was installed with 64bit:

>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\numpy\__init__.py", line 143, in <module>
    from . import _distributor_init
  File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\numpy\_distributor_init.py", line 26, in <module>
    WinDLL(os.path.abspath(filename))
  File "C:\Python39-32\lib\ctypes\__init__.py", line 374, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 193] %1 is not a valid Win32 application

I guess this isn't a very common problem, but in MSYS2 we are facing this issue because users can easily switch between 32bit/64bit Python. We could patch things, but I'm wondering if there are any plans to fix this in CPython itself so we don't invent our own thing.

thanks
msg386818 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-02-11 03:58
The conflict between 32-bit and 64-bit user site-packages was resolved in issue 41627, starting with Python 3.10. It's not practical to backport this change to existing 3.9 installations. 

The "nt_user" install scheme was changed to use the config variable "py_version_nodot_plat". For example:

    >>> sysconfig.get_path('purelib', 'nt_user', expand=False)
    '{userbase}/Python{py_version_nodot_plat}/site-packages'

This variable is based on sys.winver (i.e. the version number of the Python DLL), which includes a "-32" suffix in 32-bit Python. For example:

    >>> sys.winver
    '3.10-32'
    >>> sysconfig.get_config_var('py_version_nodot_plat')
    '310-32'
msg386829 - (view) Author: Christoph Reiter (lazka) * Date: 2021-02-11 15:43
Ah, wonderful. We'll do something similar then.

Thanks for the info and the pointer to the resolved issue. Much appreciated!
History
Date User Action Args
2022-04-11 14:59:41adminsetgithub: 87361
2021-02-11 15:43:59lazkasetmessages: + msg386829
2021-02-11 03:58:20eryksunsetstatus: open -> closed

superseder: Relocate user site packages on Windows 32-bit

nosy: + eryksun
messages: + msg386818
resolution: duplicate
stage: resolved
2021-02-10 20:05:35lazkacreate