Repository navigation
build: stop installing basicpy/aicsimageio, which break the NumPy 2 stack - #641
Merged
Alpaca233 merged 1 commit intoSep 6, 2026
Merged
Conversation
…tack basicpy pins scipy<1.13 (peng-lab/BaSiCPy#173) and scipy 1.12 ships no NumPy-2 wheel, so installing it resolves the whole environment back to numpy 1.26. That violates napari 0.7's scipy>=1.14 and opencv 5.x's numpy>=2: `pip check` reports four broken requirements and napari fails to import. The comment this replaces claimed the pinned-back packages were verified to work with NumPy 2; they are not, and the install line as it stands produces a broken environment. The only consumer of either package is control/stitcher.py, which nothing in the application imports -- no static import, no dynamic one, and tools/stitcher.py defines its own unrelated Stitcher. Stitching now lives in the separate Cephla-Lab/image-stitcher repo, so this drops no reachable functionality; stitcher.py stays on disk and can still be used from a dedicated venv.
Alpaca233
pushed a commit
that referenced
this pull request
Oct 14, 2026
…tack (#641) > **Stacked on #622.** Base is `feat/pyqt6-napari07-migration-v2` so the diff stays to a single file. Retarget to `master` once #622 lands. ## Problem The current install line produces a **broken environment**. `basicpy` pins `scipy<1.13` ([peng-lab/BaSiCPy#173](peng-lab/BaSiCPy#173)), and scipy 1.12 ships no NumPy-2 wheel — so pip resolves the whole environment back to numpy 1.26. After running `setup_22.04.sh` as written: ``` $ pip check napari 0.7.1 has requirement scipy>=1.14.0, but you have scipy 1.12.0. ome-zarr-models 1.8.0 has requirement zarr>=3.1.1, but you have zarr 2.15.0. opencv-contrib-python-headless 5.0.0.93 has requirement numpy>=2, but you have numpy 1.26.4. opencv-python-headless 5.0.0.93 has requirement numpy>=2, but you have numpy 1.26.4. pydantic-zarr 0.10.0 has requirement numpy>=2.0.0, but you have numpy 1.26.4. ``` napari then fails to import. The comment being replaced states that the pinned-back packages "were verified to work" with NumPy 2 — that does not hold once `basicpy` is in the resolution. This isn't a "prefer newer packages" cleanup: **you cannot have both** `basicpy` and a working napari in one environment, because their scipy constraints don't intersect. ## Why removal is safe `basicpy` and `aicsimageio` are imported by exactly one file, `control/stitcher.py`, and **nothing imports that module**: - no static import — `control.stitcher` / `import stitcher` match nowhere - no dynamic import — the only `__import__` uses are the MCP server's sandbox builtins and a test mock - `tools/stitcher.py` defines its **own**, unrelated `Stitcher` class and imports neither package Stitching now lives in the separate [image-stitcher](https://github.com/Cephla-Lab/image-stitcher) repo, which the README already points users to. No code is deleted: `control/stitcher.py` stays on disk and remains usable from a dedicated venv, as the new comment explains. ## Alternative If you'd rather keep it installable in-tree, a `[stitching]` extras group would work as well — happy to rework it that way. Flagging this as the judgment call in the change, since it reverses an existing claim in the script. ## Verification With these two dropped, `pip check` reports **no broken requirements**, and the suite runs **1634 passed, 0 failed, 12 skipped** under Python 3.12 / PyQt6 6.11.0 / napari 0.7.1.
Alpaca233
pushed a commit
that referenced
this pull request
Oct 17, 2026
…tack (#641) > **Stacked on #622.** Base is `feat/pyqt6-napari07-migration-v2` so the diff stays to a single file. Retarget to `master` once #622 lands. ## Problem The current install line produces a **broken environment**. `basicpy` pins `scipy<1.13` ([peng-lab/BaSiCPy#173](peng-lab/BaSiCPy#173)), and scipy 1.12 ships no NumPy-2 wheel — so pip resolves the whole environment back to numpy 1.26. After running `setup_22.04.sh` as written: ``` $ pip check napari 0.7.1 has requirement scipy>=1.14.0, but you have scipy 1.12.0. ome-zarr-models 1.8.0 has requirement zarr>=3.1.1, but you have zarr 2.15.0. opencv-contrib-python-headless 5.0.0.93 has requirement numpy>=2, but you have numpy 1.26.4. opencv-python-headless 5.0.0.93 has requirement numpy>=2, but you have numpy 1.26.4. pydantic-zarr 0.10.0 has requirement numpy>=2.0.0, but you have numpy 1.26.4. ``` napari then fails to import. The comment being replaced states that the pinned-back packages "were verified to work" with NumPy 2 — that does not hold once `basicpy` is in the resolution. This isn't a "prefer newer packages" cleanup: **you cannot have both** `basicpy` and a working napari in one environment, because their scipy constraints don't intersect. ## Why removal is safe `basicpy` and `aicsimageio` are imported by exactly one file, `control/stitcher.py`, and **nothing imports that module**: - no static import — `control.stitcher` / `import stitcher` match nowhere - no dynamic import — the only `__import__` uses are the MCP server's sandbox builtins and a test mock - `tools/stitcher.py` defines its **own**, unrelated `Stitcher` class and imports neither package Stitching now lives in the separate [image-stitcher](https://github.com/Cephla-Lab/image-stitcher) repo, which the README already points users to. No code is deleted: `control/stitcher.py` stays on disk and remains usable from a dedicated venv, as the new comment explains. ## Alternative If you'd rather keep it installable in-tree, a `[stitching]` extras group would work as well — happy to rework it that way. Flagging this as the judgment call in the change, since it reverses an existing claim in the script. ## Verification With these two dropped, `pip check` reports **no broken requirements**, and the suite runs **1634 passed, 0 failed, 12 skipped** under Python 3.12 / PyQt6 6.11.0 / napari 0.7.1.
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
2 participants
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.
Problem
The current install line produces a broken environment.
basicpypinsscipy<1.13(peng-lab/BaSiCPy#173), and scipy 1.12 ships no NumPy-2 wheel — so pip resolves the whole environment back to numpy 1.26.After running
setup_22.04.shas written:napari then fails to import. The comment being replaced states that the pinned-back packages "were verified to work" with NumPy 2 — that does not hold once
basicpyis in the resolution.This isn't a "prefer newer packages" cleanup: you cannot have both
basicpyand a working napari in one environment, because their scipy constraints don't intersect.Why removal is safe
basicpyandaicsimageioare imported by exactly one file,control/stitcher.py, and nothing imports that module:control.stitcher/import stitchermatch nowhere__import__uses are the MCP server's sandbox builtins and a test mocktools/stitcher.pydefines its own, unrelatedStitcherclass and imports neither packageStitching now lives in the separate image-stitcher repo, which the README already points users to.
No code is deleted:
control/stitcher.pystays on disk and remains usable from a dedicated venv, as the new comment explains.Alternative
If you'd rather keep it installable in-tree, a
[stitching]extras group would work as well — happy to rework it that way. Flagging this as the judgment call in the change, since it reverses an existing claim in the script.Verification
With these two dropped,
pip checkreports no broken requirements, and the suite runs 1634 passed, 0 failed, 12 skipped under Python 3.12 / PyQt6 6.11.0 / napari 0.7.1.