Problem
Over-tight runtime pins
numpy = ">=2.4.4,<3"
quimb = ">=1.14.0,<2"
numpy>=2.4.4 demands a NumPy released only weeks ago. A library should
declare the oldest version it actually works with, not the newest one that
happened to be installed when the constraint was written. As it stands,
src_method cannot be co-installed with anything that has not yet moved to the
very latest NumPy, which is a real adoption barrier for a scientific package —
users typically have a large pinned environment they cannot churn.
Nothing in the source uses a NumPy 2.4-only feature; the code is compatible far
further back.
Tool version drift
The ruff version is pinned in two places that disagree:
pyproject.toml dev group: ruff==0.15.12
.pre-commit-config.yaml: rev: v0.12.11
So pre-commit and uv run ruff can produce different results on the same
file — a hook passes locally and CI fails, or vice versa. There is an
update-ruff.yml workflow that appears to maintain one of them but not the
other.
Proposed fix
- Lower the NumPy floor to the oldest version the test suite actually passes
on. Determine it empirically rather than guessing: run the suite against
candidate floors (2.0, 2.1, 2.2) in a matrix and set the constraint to
the lowest that is green. Keep the <3 major-version cap.
- Do the same for
quimb, whose floor was likewise set to a very recent
release.
- Make
ruff single-sourced: either have update-ruff.yml bump both locations
atomically, or drop the version from one of them so there is a single source
of truth. Add a CI check that fails if the two ever diverge.
- Add the oldest supported dependency set to the CI matrix so the floor is
actually tested rather than merely asserted.
Acceptance criteria
Problem
Over-tight runtime pins
numpy>=2.4.4demands a NumPy released only weeks ago. A library shoulddeclare the oldest version it actually works with, not the newest one that
happened to be installed when the constraint was written. As it stands,
src_methodcannot be co-installed with anything that has not yet moved to thevery latest NumPy, which is a real adoption barrier for a scientific package —
users typically have a large pinned environment they cannot churn.
Nothing in the source uses a NumPy 2.4-only feature; the code is compatible far
further back.
Tool version drift
The
ruffversion is pinned in two places that disagree:pyproject.tomldevgroup:ruff==0.15.12.pre-commit-config.yaml:rev: v0.12.11So
pre-commitanduv run ruffcan produce different results on the samefile — a hook passes locally and CI fails, or vice versa. There is an
update-ruff.ymlworkflow that appears to maintain one of them but not theother.
Proposed fix
on. Determine it empirically rather than guessing: run the suite against
candidate floors (
2.0,2.1,2.2) in a matrix and set the constraint tothe lowest that is green. Keep the
<3major-version cap.quimb, whose floor was likewise set to a very recentrelease.
ruffsingle-sourced: either haveupdate-ruff.ymlbump both locationsatomically, or drop the version from one of them so there is a single source
of truth. Add a CI check that fails if the two ever diverge.
actually tested rather than merely asserted.
Acceptance criteria
quimbfloors reflect tested compatibility, not the latest release.ruffis pinned to the same version inpyproject.tomland.pre-commit-config.yaml, enforced automatically.