fix two tests that have failed CI on every run since 2026-08-19 - #267
Merged
Conversation
CI has been red on main for five consecutive merges (#261 through #266). Both failures are tests asserting a property of the INTERPRETER BUILD rather than of fusil, so both pass on the local interpreters and fail on the python.org builds setup-python installs. A permanently red CI catches nothing, which is exactly how a real regression gets in. test_builtins_still_discoverable_under_only_c asserted `math` is discovered under --only-c. Whether math is a builtin or a shared extension is a build choice: it is compiled in on both local interpreters and is an extension on CI, so the test was naming a module CI does not have. The invariant it actually guards -- a builtin has no filename, so the file-based only-c check must not drop it -- is now asserted over sys.builtin_module_names, whatever this interpreter happens to contain. test_tricky_objects_runs_without_types_CapsuleType builds a shim `types` module with every attribute except CapsuleType, to prove the prelude survives a target that lacks it. It copied `__getattr__` along with everything else -- and CPython 3.13 defines CapsuleType LAZILY through a module-level __getattr__ (PEP 562), so the copy resolved the attribute straight back to the real module and the shim stopped shimming. 3.14 defines it eagerly via _types, which is why it passed here and failed only on CI's 3.13 job. Skipping __getattr__ fixes it; verified against a simulated 3.13-style lazy `types`, since no 3.13 is installed locally. Neither fix touches fusil itself.
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.
CI has been red on
mainfor five consecutive merges — #261, #262, #263, #264, #265 (and#266, which I merged on top of it). Neither failure is caused by any of those PRs. Both
are tests asserting a property of the interpreter build rather than of fusil, so both pass
on the local interpreters and fail on the python.org builds
setup-pythoninstalls.A permanently red CI catches nothing, which is exactly how a real regression gets in.
1.
test_builtins_still_discoverable_under_only_cWhether
mathis compiled in or is a shared extension is a build choice. It is a builtin onboth interpreters here and an extension on CI, so the test was naming a module CI does not
have.
The invariant it actually guards — a builtin has no filename, so routing the seed through the
file-based
--only-ccheck must not drop it — is now asserted oversys.builtin_module_names, whatever this interpreter happens to contain.2.
test_tricky_objects_runs_without_types_CapsuleTypeThe test builds a shim
typesmodule holding every attribute exceptCapsuleType, to provethe generated prelude survives a target that lacks it (PyPy 3.11, CPython < 3.13). It copied
__getattr__along with everything else — and CPython 3.13 definesCapsuleTypelazilythrough a module-level
__getattr__(PEP 562), so the copy resolved the attribute straightback to the real module and the shim stopped shimming.
3.14 defines it eagerly via
_types, which is why this passed locally and failed only on the3.13 job. Skipping
__getattr__fixes it.No 3.13 is installed here, so I verified the mechanism against a simulated 3.13-style lazy
typesrather than claiming a test run I did not do:Scope
Tests only — no change to fusil. 1281 tests OK locally,
ruff checkandruff format --checkboth clean.