Let Windows arm64 install, since the code never needed those wheels - #483
Merged
Conversation
The entry said BLOCKED, and that was half right. opencv-python and cryptography publish no win_arm64 wheel, so pip built OpenCV from source and CMake failed to configure for ARM64. What went unmeasured is that nothing in the package imports either one at import time: with all five heavy modules blocked, the facade still binds its 1,238 public names and the executor, MCP registry, CLI and stable API all run. The blocker was the dependency list, not the code. Mark the three requirements off that one platform instead. je_open_cv carries the marker too, being pure Python that depends on OpenCV; Pillow does not, because it has always shipped win_arm64 wheels and calling it a blocker was a guess. Every other platform resolves what it did before. Say what arm64 gives up in the error itself, so a missing wheel does not read as a broken install: two accessors cover the doors every image path takes, and the crypto call sites name the platform rather than raising a bare ModuleNotFoundError. pip evaluates markers against the running interpreter, so --platform cannot prove this locally; the test evaluates the marker directly and windows-11-arm proves the install. Also make Progress.md answer the questions the tree asks of it. Two verify scripts print "see Progress.md" about the ei_unref segfault workaround and it was recorded nowhere; three permanently skipped Qt tests say "skip until then" with no entry; the coverage and mypy ramps live only in pyproject comments. Four pointers aimed at entries that had been deleted, and one of those told the reader mouse_scroll is non-portable on Linux, which stopped being true when the sign started reversing on every backend.
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 22 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
tomllib is 3.11+, and this project supports 3.10 — so the new test took the whole 3.10 collection down on all three operating systems while passing everywhere I had run it. Read the dependency array with a small regex instead; a guard that cannot run on the floor version is not a guard. Verified against a real 3.10.20 interpreter, where tomllib is genuinely absent. Mark the probe subprocess the way the identical call in test_facade_import_is_light.py is already marked: argv is this interpreter plus a module-level literal, no interpolation, no shell.
|
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
1 participant
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.
Progress.mdrecorded Windows arm64 asBLOCKED, and that was half right.opencv-pythonandcryptographypublish nowin_arm64wheel — still truetoday, re-measured before this change:
The half that went unmeasured is the one that mattered: nothing in the
package needs either wheel at import time. With
cryptography,cv2,je_open_cv,numpyandPILall blocked in a subprocess,import je_auto_controlstill binds its 1,238 public names, and the executor, the MCPtool registry, the CLI,
api.generate_codeandapi.create_failure_bundleall import and run. The blocker lived entirely in
pyproject.toml.What changed
sys_platform != 'win32' or platform_machine != 'ARM64'.je_open_cvcarries it too: it is pure Pythonbut depends on OpenCV, so leaving it unmarked drags OpenCV back in through
the side door. Pillow deliberately does not — it has always shipped
win_arm64wheels, and the earlier note calling it a blocker was a guess.windows-11-armis back inplatform-smoke.yml, 3.14 only; CPython'sofficial Windows arm64 builds start at 3.11, so the 3.10 square is excluded
with the reason in a comment.
find_image*, the OpenCVscreenshot(), the secret vault, action-fileencryption, ACME/TLS and encrypted recording raise a message saying which
wheel is missing and why, rather than a bare
ModuleNotFoundErrorthatreads like a broken install. Two accessors in
utils/cv2_utils/optional.pycover the two doors every image path takes; the other ~70 lazy
import cv2sites are left alone on purpose.
Every other platform resolves exactly the dependency set it did before —
asserted per-platform in the new test.
On verification
pip --platformdoes not overridesys_platform/platform_machineformarker evaluation — it only changes wheel-compatibility tags — so a local
--dry-runcannot prove this either way. What can, and does:test_arm64_dependency_markers.pyevaluates the marker against fiveplatforms and pins its spelling, so removing it (or "tidying" Pillow into
it) fails loudly. Mutation-checked: dropping one marker reddens 6 tests.
Requires-Distlines carry the markers.windows-11-armsquare itself is the real acceptance test.Also here
Progress.mdnow answers the questions the tree asks of it. Two verifyscripts print
*** REVISIT ***and "seeProgress.md" about theei_unrefsegfault workaround, which was recorded nowhere; three permanently skipped Qt
thread-marshal tests say "skip until then" with no entry; the coverage
(
fail_under = 35→ 70) and mypy ramps lived only inpyproject.tomlcomments. Four cross-references pointed at deleted entries — and one of them
told the reader
mouse_scrollis non-portable on Linux, which stopped beingtrue when the sign started reversing on every backend.
Local: 4,801 headless tests pass; ruff and bandit clean; no new pylint
findings (the two
auto_control_screen.pyerrors pre-exist); doc-count anddoc-line-count gates green.