Repository navigation
importlib/test_metadata_api fails on Windows buildbots #103661
Description
Activity
Failure message is:
====================================================================== ERROR: test_read_text (test.test_importlib.test_metadata_api.APITests.test_read_text) [egg_with_no_modules-pkg] ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows10\build\Lib\test\test_importlib\test_metadata_api.py", line 86, in test_read_text top_level = [ ^ IndexError: list index out of range ----------------------------------------------------------------------The tests are failing on Windows buildbots, but I struggle to think of what might be different about the buildbot environments that would affect this test.
I'm also unsure how to replicate the failure. Tests clearly pass on Windows in general. What is it about this test that makes it fail in the buildbot environments only? Since I don't have a way to triage the failure further, I'm going to mark the test as "xfail" for now to stop the buildbot failures.
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortestsTests in the Lib/test dirTests in the Lib/test dir
on Apr 21, 2023 - added a commit that references this issue
on Apr 21, 2023 Good news is I've been able to replicate the issue on a local build of CPython for Windows, so I ought to be able to inspect for the root cause.
Interestingly, it seems
PackagePath.nameis somehow not returning the name only.> c:\users\jaraco\code\python\cpython\lib\test\test_importlib\test_metadata_api.py(100)test_read_text() -> top_level = [ (Pdb) files(pkg_name) [PackagePath('egg_with_no_modules_pkg.egg-info\\PKG-INFO'), PackagePath('egg_with_no_modules_pkg.egg-info\\SOURCES.txt'), PackagePath('egg_with_no_modules_pkg.egg-info\\top_level.txt')] (Pdb) files(pkg_name)[-1].name 'egg_with_no_modules_pkg.egg-info\\top_level.txt'Aah.
PackagePathderives fromPurePosixPath, so it's not a big surprise that Windows separators aren't honored. What is more of a surprise is that this issue wasn't caught in importlib_metadata or by the Windows CI runs. Why is it only encountered by the buildbots and my local build?The issue is here, where Windows-separated paths are generated.
I also learned that the
suppress(Exception)near that line is sufficient to suppress the error. When I put a NameError in there, the tests continued to pass. Probably that trap needs to be less lenient to errors. That may explain why this failure wasn't encountered on CI runs.- added 4 commits that reference this issue
on Apr 22, 2023 importlib_metadata 6.5.1 has that when applied here will overwrite the workaround.
- added a commit that references this issue
on Apr 22, 2023 - added a commit that references this issue
on Apr 24, 2023 - added a commit that references this issue
on Apr 30, 2023 - added a commit that references this issue
on May 9, 2023 - added a commit that references this issue
on May 11, 2026 - added a commit that references this issue
on May 14, 2026
Hi! The buildbot AMD64 Windows10 3.x has failed when building commit 3e0fec7.
What do you need to do:
You can take a look at the buildbot page here:
https://buildbot.python.org/all/#builders/146/builds/4915
Failed tests:
Failed subtests:
Summary of the results of the build (if available):
== Tests result: FAILURE then FAILURE ==
399 tests OK.
10 slowest tests:
1 test failed:
test_importlib
34 tests skipped:
test_clinic test_curses test_dbm_gnu test_dbm_ndbm test_devpoll
test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl
test_kqueue test_multiprocessing_fork
test_multiprocessing_forkserver test_nis test_openpty
test_ossaudiodev test_peg_generator test_perf_profiler test_pipes
test_poll test_posix test_pty test_pwd test_readline test_resource
test_spwd test_syslog test_threadsignals test_wait3 test_wait4
test_xxlimited test_xxtestfuzz test_zipfile64
1 re-run test:
test_importlib
Total duration: 20 min 48 sec
Click to see traceback logs
Originally posted by @bedevere-bot in #103584 (comment)
Linked PRs