Installing and running both 32 bit and 64 bit python at the same time -module issues

Question

I have one module that only runs on 32 bit python. I then have subprocesses that need to launch on 64 bit python for memory reasons. There are also about 8 modules that I need to use. I installed everything and actually had both the 32 bit and 64 bit versions running at the same time. But then had to install one more module 'datetime'. After I installed that it went back to this issue. I tried uninstalling 'datetime' and that did not fix.

OSError: [WinError 193] %1 is not a valid Win32 application

So I followed advice to do what originally seemed to allow both to run by using pip install -- pywin32==227

That said it was already satisfied so I tried pip install -- pywin32==228 then back to pip install -- pywin32==227

Still this error OSError: [WinError 193] %1 is not a valid Win32 application

I noticed that despite having two versions of python (32 and 64 bit) in two different folders it is storing all modules in \AppData\Roaming\Python\Python39\site-packages and I am wondering how it distinguishes between a 32 bit module install and a 64 bit.

The most frustrating thing about this issue is for one brief moment, I actually had both running so I know it is possible, but not sure how at this point. Is there a recommended way to have two (32 and 64) bit pythons running at the same time with two unique sets of modules installed? At this point, I would start over with all of the installations as needed.

Answer 1

The problem is that python uses the same location for site.getusersitepackages() for 32-bit and 64-bit versions of python.

It appears that your installation process for your modules is using usersitepackages because you specified the directory causing you problems was \AppData\Roaming\Python\Python39\site-packages which is usersitepackages which appears earlier than the regular site-packages in sys.path (but only if the directory exists - hence not everybody knows about usersitepackages).

This seems to be a bug with the Python release - it has annoyed me as well since I prefer to install my extensions in usersitepackages since I may not have write access to the regular site-packages directory.

You can fix it as follows:

Edit the file Lib/site.py in your Python package (of course you might not have write access - see above).

There is a function called _get_path in this file which looks a bit like this:

def _get_path(userbase):
    version = sys.version_info
    if os.name == 'nt':
        return f'{userbase}\\Python{version[0]}{version[1]}\\site-packages'

So very good - it gets the right version of Python - but does nothing about the number of bits. Since we are recoding this function you should do this:

return f'{userbase}\\Python{version[0]}{version[1]}-32\\site-packages'

or this:

return f'{userbase}\\Python{version[0]}{version[1]}-64\\site-packages'

depending on whether you are editing the 32-bit version or the 64-bit version.

I suppose you could find out the architecture if you wanted to be pure and logical (in order to have the same implementation of site.py for all releases).

eg

import platform
platform.architecture()[0]

should return 32bit or 64bit - so this is what I think the Python development team should do if they read this comment.