Python broke in v2.5.0

[imphil]

The release v2.5.0 broke running Python in GH Actions with under msys, it worked in 2.4.2.

Our workflow:
https://github.com/cocotb/cocotb/blob/1123973ed6979f89b8e1cb8785d5ae7c425d2908/.github/workflows/regression-tests.yml#L334-L371

Python aborts execution right after start with the following message:

Python path configuration:
  PYTHONHOME = 'D:/a/_temp/msys/msys64/mingw64'
  PYTHONPATH = (not set)
  program name = 'D:/a/_temp/msys64/mingw64/bin/python.exe'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = 'D:/a/_temp/msys64/mingw64/bin/python.exe'
  sys.base_prefix = 'D:/a/_temp/msys/msys64/mingw64'
  sys.base_exec_prefix = 'D:/a/_temp/msys/msys64/mingw64'
  sys.platlibdir = 'lib'
  sys.executable = 'D:/a/_temp/msys64/mingw64/bin/python.exe'
  sys.prefix = 'D:/a/_temp/msys/msys64/mingw64'
  sys.exec_prefix = 'D:/a/_temp/msys/msys64/mingw64'
  sys.path = [
    'D:/a/_temp/msys/msys64/mingw64/lib/python39.zip',
    'D:/a/_temp/msys/msys64/mingw64/lib/python3.9',
    'D:/a/_temp/msys/msys64/mingw64/lib/python3.9/lib-dynload',
    '',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

There's much more information available at cocotb/cocotb#2739

The most likely reason for this change in behavior seems to be like #163. Do you have any idea what's going on?

Note PYTHONHOME is referring to (as far as I read the PR) the "old" installation path, 'D:/a/_temp/msys/msys64/mingw64', while the Python binary is in the new installation path.

[eine]

@lazka, I guess we need to have some packages regenerated on the new setup? That is, this issue is transitory because some packages were built with the old setup but are being executed on the new.

[jeremyd2019]

If any package 'knows' the GHA path and doesn't work elsewhere, that package is broken, because a user is unlikely to install msys2 in D:\a\_temp\...

[eine]

@jeremyd2019 maybe it's the cache of their MSYS2 job in CI the one remembering old paths?

[lazka]

I guess the problem is this: https://github.com/cocotb/cocotb/blob/0346c035f0e1fac432c5a35ea38b95787e7d7223/cocotb/share/makefiles/Makefile.inc#L74 (why no one else has the problem)

This returns the wrong path, needs investigating:

$ python -c 'from sysconfig import get_config_var; print(get_config_var("prefix"))'
D:/a/_temp/msys/msys64/ucrt64

I'm not sure if prefix is supposed to be relocated though, seems to be an autotools path.

[eine]

Maybe we should support optionally specifying msysRootDir as an absolute path?

[lazka]

Maybe we should support optionally specifying msysRootDir as an absolute path?

No, this is unrelated to this action. It would fail the same way outside of CI.

I've created msys2-contrib/cpython-mingw#51

[eine]

@lazka my point is that this did not arise before because the prefix did match (when building Python in CI and when using it in CI). As soon as Python is updated using the new CI setup, the cocotb CI will work again. However, that does not imply fixing msys2-contrib/cpython-mingw#51. If cocotb could use a different absolute path for their regular CI, future issues such as this would be found.

[lazka]

Ah, I see. Or we could use a different path in autobuild.

[ktbarrett]

@lazka Read this: https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHOME. prefix and PYTHONHOME should be one in the same. We put that line in place based on the following recommendation. PYTHONHOME and the path to the Python standard library can be deduced from the Python executable, but apparently not necessarily from libpython, so you are expected to help it out. The only way we can do that is by invoking Python and asking it what it thinks PYTHONHOME should be.

[RivenSkaye]

I've compiled vim for use in MingW64 (the msys/vim package shits itself when externals like Python are being called on) and noticed some very odd behavior on a plugin crashing.
When running python for an interactive session in the MingW shell, output seems to be normal. The same holds true when running a script:

>>> import sys
>>> print(sys.path)
['', 'C:/msys64/mingw64/lib/python311.zip', 'C:/msys64/mingw64/lib/python3.11', 'C:/msys64/mingw64/lib/python3.11/lib-dynload', 'C:/msys64/mingw64/lib/python3.11/site-packages']

However, when running in vim (and perhaps other programs too):

:py3 import sys; print(sys.path)
>>> Could not find platform dependent libraries <exec_prefix>
>>>['C:/msys64/mingw64/lib/python311.zip', 'C:/msys64/mingw64/lib/python3.11', 'D:/a/msys64/mingw64/lib/python3.11/lib-dynload', 'C:/msys64/mingw64/lib/python3.11/site-packages', '_vim_path_']

This bars importing some stdlib components like the math module and causes some plugins like UltiSnip to downright crash. It also causes an error on init, which vim handles gracefully but I expect other programs might not.

Perhaps the issue here lies in where the DLL gets loaded from? Seems to be related to this though

EDIT: compiling with the PYTHON3_HOME flag for vim set causes the same crash as OP had, but with the paths listed as from a working vim build. It also sets PYTHON_HOME to the flag's value when crashing in vim, regardless of what it'd otherwise use.