-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
gh-108927: Fix removing testing modules from sys.modules #108952
gh-108927: Fix removing testing modules from sys.modules #108952
Conversation
It breaks import machinery if the test module has submodules used in other tests.
4f7617c
to
339f260
Compare
Presumably the reload (the reason for the unload) was intentional. Do we know why that was added? Do those reasons still apply? |
Lib/test/libregrtest/runtest.py
Outdated
@@ -434,10 +434,6 @@ def regrtest_runner(result, test_func, ns) -> None: | |||
def _load_run_test(result: TestResult, ns: Namespace) -> None: | |||
# Load the test function, run the test function. | |||
module_name = abs_module_name(result.test_name, ns.testdir) | |||
|
|||
# Remove the module from sys.module to reload it if it was already imported | |||
sys.modules.pop(module_name, None) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum. I think that the problem is that only a single module is unload from sys.modules.
If we want to save/restore modules, IMO the whole sys.modules
dictionary must be saved/restored. Not a single entry.
Would it make sense to save/restore the whole sys.modules dict? Would it fix #108927 ?
Tests crash with this change, and it means that there is other huge issue hidden until now.
It is already done in |
Unloading the test module is done for 23 years (commit 5796d26) and so far, so I'm surprised that today it became a problem. Maybe it's not the right place to fix the issue.
|
I would prefer to dig deeper before changing this code. |
The crash is not related to this change. See #108976. If exclude test_pdb, all tests are passed successfully. |
Ah, that code does not work since 3.0. It saves |
Lib/test/libregrtest/main.py
Outdated
@@ -318,9 +318,9 @@ def run_tests_sequentially(self, runtests): | |||
result = self.run_test(test_name, runtests, tracer) | |||
|
|||
# Unload the newly imported modules (best effort finalization) | |||
for module in sys.modules.keys(): | |||
for module in list(sys.modules): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for module in list(sys.modules): | |
for module in sys.modules: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it does not work, because the dict is modified during iteration.
Misc/NEWS.d/next/Tests/2023-09-05-20-46-35.gh-issue-108927.TpwWav.rst
Outdated
Show resolved
Hide resolved
…Wav.rst Co-authored-by: Brett Cannon <[email protected]>
Lib/test/libregrtest/main.py
Outdated
@@ -318,9 +318,9 @@ def run_tests_sequentially(self, runtests): | |||
result = self.run_test(test_name, runtests, tracer) | |||
|
|||
# Unload the newly imported modules (best effort finalization) | |||
for module in sys.modules.keys(): | |||
for module in list(sys.modules): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this code. Why do we have to unload test modules?
If it's important to unload test modules, I would suggest to move this code inside single.py, to make a more consistent behavior for the different ways to run tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you ask why the code of libregrtest is so complicated? 🤷♂️
I think that it only makes sense in the single-process run. As well as removing the testing module before reloading in _load_run_test()
. In the multi-process run it is only a waste of time. As well as significant part of save_env
(except cleaning up external resources like filesystem).
Oh... I see :-) So if the code is dead for 20+ years, maybe remove it? I don't know what's the best option here. I would expect that running a test would restore Python (sys.modules) in the exact same state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for updated tests. I confirm that tests fail I revert Lib/test/libregrtest/ changes.
Co-authored-by: Victor Stinner <[email protected]>
Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12. |
GH-112711 is a backport of this pull request to the 3.12 branch. |
…nGH-108952) It breaks import machinery if the test module has submodules used in other tests. (cherry picked from commit e08b70f) Co-authored-by: Serhiy Storchaka <[email protected]>
GH-112712 is a backport of this pull request to the 3.11 branch. |
…nGH-108952) It breaks import machinery if the test module has submodules used in other tests. (cherry picked from commit e08b70f) Co-authored-by: Serhiy Storchaka <[email protected]>
…08952) (ПР-112712) It breaks import machinery if the test module has submodules used in other tests. (cherry picked from commit e08b70f) Co-authored-by: Serhiy Storchaka <[email protected]>
…08952) (ПР-112711) It breaks import machinery if the test module has submodules used in other tests. (cherry picked from commit e08b70f) Co-authored-by: Serhiy Storchaka <[email protected]>
It looks like the new test fails when running the tests from an installed Python installation (see https://buildbot.python.org/all/#/builders/350/builds/4974 and https://buildbot.python.org/all/#/builders/1154/builds/418), could someone take a look? |
FTR we are seeing the failures with the recently released 3.11.7. |
I suppose that #112784 already fixed the issue in the 3.11 branch. Sadly, this fix is not part of 3.11.7 release. Buildbots were too slow to report the failure on the 3.11 branch before the release? It seems like we have "Installed" buildbot builders on the 3.11 branch. |
Yes. What's done is done, but may I suggest a release not be made with commits before the buildbots have time to recognize a failure? |
Ah right, there were less than 1 hour between the commit and the tag.
Usually, the branch is not locked around bugfix 3.x.y releases. cc @pablogsal 3.11 release manager. |
The release script blocks if there are failing build bots so this was releaseable because all buildbots were green at the time (or the API reported green). Is very difficult to time this correctly because even if we block a branch we do this hours before the release so we don't know when all builsbots have finished. We can discuss blocking a day in advance to prevent this from happening or some other mechanism. I will discuss this with other RMs to see what can be done. |
In my experience, it's rare to discover bugs so soon just after a release. I'm not sure that it's worth it to deeply change the release process. Maybe the release process should run tests on installed Python, rather than in the source code directory. |
…nGH-108952) It breaks import machinery if the test module has submodules used in other tests.
…nGH-108952) It breaks import machinery if the test module has submodules used in other tests.
The code that does this properly never worked since Python 3.0.
And removing only the tested module breaks import machinery if it has submodules used in other tests.