pymmcore.CMMCore 11.1.1.71.1 not playing nicely with PyQt5 on Windows

[tlambert03]

still trying to debug this, but I've noticed that I can no longer instantiate a CMMCore object on windows anymore if pymmcore was imported after PyQt5. I eventually narrowed it down to this minimal example, which crashes on pymmcore 11.1.1.71.1, but not on 11.1.1.71.0

import os
import site
site_packages = site.getsitepackages()[-1]
qt_binaries = rf'{site_packages}\PyQt5\Qt5\bin'

# this line makes pymmcore crash, provided it comes before importing pymmcore
os.add_dll_directory(qt_binaries)

from pymmcore import CMMCore
core = CMMCore()

I looked inside PyQt5\Qt5\bin for what might be causing the problem, and it's the MSVC++ redistributable file: \PyQt5\Qt5\bin\msvcp140.dll. If I remove that file from the directory, pymmcore 11.1.1.71.1 works again.

Now I'm going to try to figure out what changed between 11.1.1.71.0 and 11.1.1.71.1 that might have caused the presence of that file to now crash pymmcore. @marktsuchida any thoughts?

[marktsuchida]

This has to do with the lax model used by PyPI packages to distribute the MSVC C++ standard library: packages that require it are recommended to do so, but there's a problem: the first msvcp140.dll that happens to get loaded stays. So it should be possible to get import-order-dependent problems. (Conda should not have problems like this, at least in theory.)

Because we use GitHub actions to build pymmcore, it's probably built against the latest C++ runtime. If PyQt5 is shipping an older one, then in theory it could be incompatible (though in practice I'm a little surprised, since we should not be using anything that depends on the latest C++ features).

We do not currently ship the C++ runtime with pymmcore. My thinking here was that anybody running pymmcore on Windows has run the Micro-Manager installer, which has installed (some version of) it on the system. But perhaps we need to think about this again. Alternatively we can try and see if we can build pymmcore against a slightly older MSVC (such as 2019), so that the chances of encountering an older runtime is very low.

Of course, this is theoretical -- I suppose it's possible that some other cause is at play here.

[tlambert03]

ah very useful. So do you think the only thing that might have changed between 11.1.1.71.1 and 11.1.1.71.0 is just the actions runner image?

[marktsuchida]

just the actions runner image?

Yes, and VS2022's C++ had a "minor version increment" between our two last releases, although I have no idea if that was the exact reason.