Breaking (and breaking pip) in MinGW Python running on Windows Server 2008

[ferdnyc]

After haranguing my project collaborators on the importance of at least trying to stay within a few years of the latest release of our dependencies, and having been subsequently punished for my efforts by being saddled with the upgrade tasks, I'm now finding myself in the predictable position of having to eat my words.

My attempts at upgrading the Python packages in our MSYS2-based MinGW environments hit something of a snag when I discovered that all attempts to run pip in my newly-upgraded mingw-w64-x86_64-python-3.8.9-1 or mingw-w64-i686-python-3.8.9-1 python3 interpreters fails with a traceback that winds through appdirs and into winreg, where it logs a FileNotFoundError accessing the registry.

This is true any way I can find to run pip:

• from the /mingw64/usr/bin/pip launcher provided by the MSYS2-installed mingw-w64-x86_64-python-pip package
• directly from the same module using python3 -m pip ...
• in the vendored appdirs bundled with pip itself, when using the get-pip.py script downloaded from PyPi.

And it even occurs when pip isn't involved, as long as appdirs is involved.

The same doesn't occur in the MSYS shell, likely because the MSYS shell identifies the host as Unix-like, and wouldn't be poking around for info in the native Windows registry.

I created a brand new, blank-slate user account (with Administrator privileges) and tried this from that account — the results were the same.

Here's an example of the traceback, in isolation and without any pip complications:

$ python3 -m appdirs
-- app dirs 1.4.4 --
-- app dirs (with optional 'version')
user_data_dir: C:/Users/builder/AppData/Local/MyCompany/MyApp/1.0
user_config_dir: C:/Users/builder/AppData/Local/MyCompany/MyApp/1.0
user_cache_dir: C:/Users/builder/AppData/Local/MyCompany/MyApp/Cache/1.0
user_state_dir: C:/Users/builder/AppData/Local/MyCompany/MyApp/1.0
user_log_dir: C:/Users/builder/AppData/Local/MyCompany/MyApp/1.0/Logs
Traceback (most recent call last):
  File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:/msys64/mingw64/lib/python3.8/site-packages/appdirs.py", line 593, in <module>
    print("%s: %s" % (prop, getattr(dirs, prop)))
  File "C:/msys64/mingw64/lib/python3.8/site-packages/appdirs.py", line 424, in site_data_dir
    return site_data_dir(self.appname, self.appauthor,
  File "C:/msys64/mingw64/lib/python3.8/site-packages/appdirs.py", line 134, in site_data_dir
    path = os.path.normpath(_get_win_folder("CSIDL_COMMON_APPDATA"))
  File "C:/msys64/mingw64/lib/python3.8/site-packages/appdirs.py", line 475, in _get_win_folder_from_registry
    dir, type = _winreg.QueryValueEx(key, shell_folder_name)
FileNotFoundError: [WinError 2] The system cannot find the file specified

IIUC, CSIDL_COMMON_APPDATA is a Vista+ thing, correct? Would Windows Server 2008 qualify as "Vista+"? (My impression was, no, it wouldn't. But I'm not very confident in that.)

[ferdnyc]

Windows Server 2008

To be more precise, the installed OS is Windows Server 2008 R2 Datacenter, Service Pack 1.

[ferdnyc]

Apologies. The rather cryptic and misleading traceback aside, the problem appears to have been caused by an out-of-date msys-ffi DLL.