gh-156404: Restore the 'fullname' variable for .pth import lines - #156406
Open
arcivanov wants to merge 1 commit into
Open
gh-156404: Restore the 'fullname' variable for .pth import lines#156406arcivanov wants to merge 1 commit into
arcivanov wants to merge 1 commit into
Conversation
PEP 829 moved .pth handling from site.addpackage() into StartupState._exec_imports(), and the local holding the path of the .pth file being processed was renamed from 'fullname' to 'filename'. Import lines in .pth files generated before Python 3.15 read that local, so they now fail with NameError on every interpreter startup. Inject 'fullname' into the frame which executes pth code, next to the 'sitedir' shim added for pythongh-149671. Reported downstream as karellen/wheel-axle#38
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PEP 829 moved
.pthhandling out ofsite.addpackage()and intosite.StartupState._exec_imports().importlines in.pthfiles are stillexec()'d there, but the local variable holding the path of the.pthfile being processed was renamed fromfullnametofilenamein the move, so.pthfiles generated before 3.15 that readfullnamenow raiseNameErroron every interpreter startup:This is the same class of regression as gh-149671, which was fixed in f7ab7c4 by injecting the
sitedirlocal for compatibility with the-nspkg.pthfiles generated by setuptools. This change givesfullnameidentical treatment, immediately below that existing shim.PEP 829 keeps executing
.pthimportlines through 3.17, so the old mechanism has not been retired; the lines still run, they just run against a frame that no longer exposes the name they were written against. Bothfullnameandfilenameare bound after this change, so.pthfiles written for either naming work.Real-world impact: every wheel built by
wheel-axlebefore 0.0.13 installs a.pthcontainingimport wheel_axle.runtime; wheel_axle.runtime.finalize(fullname);, and such wheels are already published. The interpreter still starts, becausesiteprints the traceback and continues, but the post-install hook never runs, so the symlinks the wheel declares are never created, and the error repeats on every startup because the.pthis never consumed. Downstream tracking issue: karellen/wheel-axle#38Adds
test_fullname_variablealongside the existingtest_sitedir_variable. Verified with--with-pydebugon both branches: the new test fails with theNameErrorabove before the change and passes after it.test_site/test_venvare green onmain(run=149 skipped=16) and on3.15atv3.15.0rc1-86-gd0484ab51a7(run=139 skipped=15).3.15is affected identically and needsneeds backport to 3.15.