Same userbase for 32bit and 64bit install on Windows causing conflicts

[lazka]

BPO	43195
Nosy	@pfmoore, @tjguk, @zware, @eryksun, @zooba, @lazka
Superseder	bpo-41627: Relocate user site packages on Windows 32-bit

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-02-11.03:58:20.071>
created_at = <Date 2021-02-10.20:05:35.554>
labels = ['3.9', 'OS-windows']
title = 'Same userbase for 32bit and 64bit install on Windows causing conflicts'
updated_at = <Date 2021-02-11.15:43:59.475>
user = 'https://github.com/lazka'

bugs.python.org fields:

activity = <Date 2021-02-11.15:43:59.475>
actor = 'lazka'
assignee = 'none'
closed = True
closed_date = <Date 2021-02-11.03:58:20.071>
closer = 'eryksun'
components = ['Windows']
creation = <Date 2021-02-10.20:05:35.554>
creator = 'lazka'
dependencies = []
files = []
hgrepos = []
issue_num = 43195
keywords = []
message_count = 3.0
messages = ['386804', '386818', '386829']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'lazka']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '41627'
type = None
url = 'https://bugs.python.org/issue43195'
versions = ['Python 3.9']

[lazka]

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

[eryksun]

The conflict between 32-bit and 64-bit user site-packages was resolved in bpo-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'

[lazka]

Ah, wonderful. We'll do something similar then.

Thanks for the info and the pointer to the resolved issue. Much appreciated!