-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_pkgutil:test_name_resolution fails on macOS HFS+ file systems #85326
Comments
After configuring and building using the command:
I ran the test suite (without changing anything) and saw that test_pkg has failed. Here is the output of == CPython 3.10.0a0 (heads/master:cd3c2bdd5d, Jun 28 2020, 13:29:09) [Clang 9.0.0 (clang-900.0.39.2)] ====================================================================== Traceback (most recent call last):
File "/Users/rahuljha/Documents/cpython/Lib/test/test_pkgutil.py", line 262, in test_name_resolution
mod = importlib.import_module(uw)
File "/Users/rahuljha/Documents/cpython/Lib/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'é' Ran 24 tests in 0.186s FAILED (errors=1) == Tests result: FAILURE == 1 test failed: Total duration: 482 ms ====================================================================== Traceback (most recent call last):
File "/Users/rahuljha/Documents/cpython/Lib/test/test_pkgutil.py", line 262, in test_name_resolution
mod = importlib.import_module(uw)
File "/Users/rahuljha/Documents/cpython/Lib/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'é' Ran 24 tests in 0.184s FAILED (errors=1) == Tests result: FAILURE == 1 test failed: Total duration: 635 ms |
This same failure is observed with the most recent 3.9beta (3.9.0b3) when running on macOS 10.9 with the binaries from the python.org macOS installer. However, no failure is seen when running the same Python on macOS 10.15. I have not investigated further with other releases. This test failure should be addressed prior t0 3.9.0rc1. |
PS, the problem may have been introduced by the changes for bpo-12915. |
The problem appears to be in importlib. I put in a breakpoint in the test just before it tries to import the module é. (At this point it has successfully imported a module called वमस in an earlier loop iteration.) Then, in a different terminal console, I cd'd to the test directory and tried the import directly:
$ ls -l
total 0
drwxr-xr-x 3 xxxxxxxx xxxxx 102 29 Jun 17:55 é
drwxr-xr-x 4 xxxxxxxx xxxxx 136 29 Jun 17:55 वमस
$ ~/projects/cpython/python.exe
Python 3.10.0a0 (heads/master:a3ad95d, Jun 29 2020, 17:50:09)
[Clang 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import वमस
>>> import é
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'é' So for some reason, importlib is failing to import the é module. (The é/init.py is a zero-byte file.) Adding Brett to nosy. |
I wonder if it's a problem from Unicode representation since I don't think importlib tries to have a standard normalization form of Unicode. I could see that leading to how the file system encoded something differing from how it was encoded in the test file, leading to a claim the file doesn't exist. And thanks to binary file paths that isn't necessarily a wrong result. :P |
That does seem to be the issue. In particular, there are differences in Unicode representation between file names on traditional HFS+ versus the newer APFS. APFS is the default for system file systems as of macOS 10.13; unlike HFS+, APFS is by default file name normalization insensitive. By creating two disk image files systems on a current macOS system, it's easy to demonstrate that test_name_resolution passes on APFS but fails on HFS+. So the question becomes what to do about the test. Without digging into it further, I suppose we could add something to test whether the file system where test temp files are created is normalization insensitive and, if so, skip. Or use brute force and always skip on macOS. In any case, while annoying, it probably doesn't need to be a "deferred blocker". |
I think if we can craft a skip check that is targeted enough then that's our best solution, but barring that then skipping for all of macOS wouldn't be the end of the world (maybe a slightly less brute force is a macOS version check?). |
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: