Executable python application may fail depending on temp folder

[AdrianEggenberger]

Hi

I've analyzed a strange issue with python based windows executable built with pyinstaller. The executable could be built without an issue, but when the tool was started the following error occurs:

File "site-packages\PyInstaller\hooks\rthooks\pyi_rth_pkgres.py", line 13, in <module>
File "<frozen importlib._bootstrap>", line 983, in _find_and_load
File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\PyInstaller\loader\pyimod03_importers.py", line 489, in exec_module
File "site-packages\pkg_resources\__init__.py", line 3251, in <module>
File "site-packages\pkg_resources\__init__.py", line 3235, in _call_aside
File "site-packages\pkg_resources\__init__.py", line 3264, in _initialize_master_working_set
File "site-packages\pkg_resources\__init__.py", line 574, in _build_master
File "site-packages\pkg_resources\__init__.py", line 567, in __init__
File "site-packages\pkg_resources\__init__.py", line 623, in add_entry
File "site-packages\pkg_resources\__init__.py", line 1983, in find_eggs_in_zip
File "site-packages\pkg_resources\__init__.py", line 1414, in has_metadata
File "site-packages\pkg_resources\__init__.py", line 1853, in _has
File "site-packages\pkg_resources\__init__.py", line 1716, in _zipinfo_name
AssertionError: C:\Users\A9447~1.EGG\EGG-INFO\PKG-INFO is not a subpath of C:\Users\A9447~1.EGG\AppData\Local\Temp\_MEI120962\base_library.zip\
[10872] Failed to execute script pyi_rth_pkgres

After a while I've found out that the same executable works properly on other workstations or even with other user accounts.
I guess I've found the root cause for my problem in the file "pkg_ressources.py" of the setuptools. In the function "_setup_prefix" is a test if a path ends with ".egg", what is the case in my situation for my temporairy folder (=> "C:\Users\A9447~1.EGG"). This causes that a new invalid path was built and afterwards caused the assertion. "C:\Users\A9447~1.EGG" is the default temp folder for my user "a.eggenberger".

The quick solution was to set another user temp folder "C\:Temp". This solved the behavior and it works as expected.

To avoid that other users with a lastname starting with "egg" the code in the _setup_prefix function should be improved.

Regards Adrian

[jaraco]

This might be a contender for one of the most obscure bugs I've seen. Not only does it depend on the fact that your last name begins with "egg" but it also depends on the fact that the egg-prefixed name appears in the last segment of the pathname, and it depends on the fact that you're on Windows, which provides compatibility with the decades-old 8.3 convention. I suspect there's another factor at play too that's causing the 8.3 filename to be used instead of the proper full filename.

[AdrianEggenberger]

"This might be a contender for one of the most obscure bugs I've seen."
=> I totally agree with that... :-)

[jaraco]

I took a stab at a fix in #2153, but was unsuccessful. I welcome help on this one.

[jaraco]

Adrian: I've got an update in #2153 that fixes the test failures. Could you test to see if it addresses your issue? Use pip install -i https://m.devpi.net/jaraco/dev setuptools==46.4.0.post20200703 to get the build at 9372bf7.

[kokroo]

This bug motivated me to quit software development and start woodworking.

[AdrianEggenberger]

This bug motivated me to quit software development and start woodworking.

I could totally understand this. 😃

It was actually the first time that my last name had an impact to an application crash.

[burnpanck]

As obscure this bug may be, one of our users may have run into this or something related today. At least the error message matches, and the username begins with "egg" too. Generally, we're using up-to-date software versions, so I would have imagined that the fix for this issue should be in. I haven't verified this explicitly yet though.

[jaraco]

The fix was added in 49.6.0, so I'd compare your installed version of Setuptools to determine if it's affected.

[burnpanck]

Ah, there we go. In CI, our version of python was pinned at chocolatey's 3.9.2, which was shipping 49.1.0. Thanks for the pointer!