Nuitka: Scoop Python is not supported yet

This is a regression, not already reported or fixed. Same thing with develop (08979ecda9db9c4d589f172a61dcb0ecc027535a).

2.0rc1
Commercial: None
Python: 3.11.6 (tags/v3.11.6:8b6ee5b, Oct  2 2023, 14:57:12) [MSC v.1935 64 bit 
(AMD64)]
Flavor: Unknown
Executable: c:\Build\project\.venv\Scripts\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 10
Version C compiler: ~\AppData\Local\Nuitka\Nuitka\Cache\downloads\gcc\x86_64\13.2.0-16.0.6-11.0.1-msvcrt-r1\mingw64\bin\gcc.exe (gcc 13.2.0).

How did you install Nuitka and Python

pip install nuitka in an activated .venv

PySide6-Essentials==6.6.0

bug.py

# nuitka-project: --standalone
# nuitka-project: --static-libpython=no
# nuitka-project: --enable-plugin=pyside6
# nuitka-project: --nofollow-import-to=tkinter
# nuitka-project: --nofollow-import-to=pytest

from PySide6.QtWidgets import QApplication

QApplication()
print("Done")

Then, nuitka bug.py && bug.dist\bug.exe:

PySide6/__init__.py: Unable to import Shiboken from C:\Build\project\bug.dist, C:\Build\project\BUG~1.DIS
Traceback (most recent call last):
  File "C:\Build\project\BUG~1.DIS\bug.py", line 7, in <module>
  File "C:\Build\project\BUG~1.DIS\PySide6\__init__.py", line 124, in <module PySide6>
  File "C:\Build\project\BUG~1.DIS\PySide6\__init__.py", line 64, in _setupQtDirectories
  File "C:\Build\project\BUG~1.DIS\shiboken6\__init__.py", line 27, in <module shiboken6>
ImportError: LoadLibraryExW 'C:\Build\project\BUG~1.DIS\shiboken6\Shiboken.pyd' 
failed: The specified module could not be found.

However:

dir bug.dist\shiboken6\Shiboken.pyd

 Directory of C:\Build\project\bug.dist\shiboken6

11/23/2023  05:58 PM            31,888 Shiboken.pyd
               1 File(s)         31,888 bytes

Process Manager says it is looking for python3.dll, which is missing in bug.dist. When building with 1.8.6, that file is present.

About this issue

Original URL
State: closed
Created 7 months ago
Comments: 17 (10 by maintainers)

Most upvoted comments

Part of the 1.9.3 release I just made.

kayhayen on Dec 2, 2023

So, I think I noticed what’s going on, the sys.path retaining the original filename with the junction is fully desired, and wanted, and scan directories already are properly covered, but when dependency walker it being called on a DLL, the original filename of that DLL (e.g. extension module) is used on the command line, which is a small issue by itself, this could e.g. be a Chinese module name, that then wouldn’t work.

The external use path indeed can be using Junctions, and my suspect is that dependency walker just doesn’t handle that, and our function to resolve symlinks is not really good at it, only doing the last level, and not all the way up, which os.path.realpath does. I think I will want to add a recursive usage of it, inside getExternalUsePath such that it is going to work independent of the level of symlink support in the used Python, that shouldn’t be too hard.

kayhayen on Nov 25, 2023

So, just making the Python prefix for 3.9 a junction, and clearing all caches, does indeed reproduce the issue, which is absolutely interesting. When googling up, I also noticed that symlinks are not nearly recommendable.

I do not want to mix symlink resolution and external use in this way, unless where it’s necessary. For the python prefix, it absolutely is, for other things, maybe not so much.

In terms of fixit it, I think I need to make compilation reports capable of pointing out the difference between using the junction and not. From my experiment, python_prefix is resolved, but I guess, sys.path probably is not, that kind of thing.

kayhayen on Nov 25, 2023