fix(ci): cap torch <2.3 on Python 3.9 so poetry resolves (#101)

[jhamon]

What

Splits the torch optional dependency into per-Python constraints so Poetry can resolve the dependency graph on Python 3.9:

torch = [
    { version = ">=1.13.1,<2.3", python = "<3.10", optional = true },
    { version = ">=1.13.1", python = ">=3.10", optional = true },
]

Why

The Run tests (ubuntu-latest, 3.9) matrix cell fails at poetry install on every PR (pre-existing, environmental). Root cause: the unbounded torch >=1.13.1 constraint. torch ≥2.3 pulls a triton → setuptools (>=40.8.0, py>=3.10) chain, so no torch version satisfies the graph on Python 3.9 → version solving fails.

Capping torch to <2.3 on Python <3.10 (torch 2.2.2 ships 3.9 wheels) keeps 3.9 resolvable while leaving 3.10+ on the open range.

Non-breaking

Preserves the existing python = ">=3.9,<4.0" support matrix rather than dropping 3.9. Dropping 3.9 (issue #101 option 1) remains a separate support-matrix decision for the maintainers; this change unblocks CI without pre-empting it.

Verification

Local, mirroring what CI does (repo doesn't commit poetry.lock; CI re-resolves via poetry install):

• poetry check → All set!
• poetry lock → resolves and writes lock (torch 2.2.2 for py<3.10, newer for py≥3.10). The same command failed with version solving failed before this change.

Fixes #101.

🤖 Generated with Claude Code

---

Note

Low Risk
Packaging-only change in pyproject.toml with no application code changes; main effect is which torch versions Poetry can select on Python 3.9.

Overview
Replaces the single optional torch >=1.13.1 constraint with Python-specific markers so Poetry can resolve installs on 3.9: >=1.13.1,<2.3 when python < 3.10, and the previous open lower bound on 3.10+.

This addresses CI failures on the 3.9 matrix job (poetry install with --all-extras), where torch ≥2.3 pulls dependencies that require Python ≥3.10, making version solving impossible. 3.9 users who opt into torch extras are effectively capped at 2.2.x (still within >=1.13.1); behavior on newer Python versions is unchanged.

^{Reviewed by Cursor Bugbot for commit b08f703. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jhamon]

Update: the torch<2.3 cap resolves Poetry but does not make CI green — this path is a dead end

Latest CI on this branch (run 29449063794):

• ✅ ubuntu-latest, 3.9 — now passes (the original version solving failed is fixed)
• ❌ macos-latest, 3.9 — 16 failed, 65 passed
• ❌ windows-latest, 3.9 — fails the same way

The cap traded a resolve-time failure for run-time failures. Two independent root causes, both intrinsic to pinning py3.9 onto old torch:

1. RuntimeError: Numpy is not available — torch 2.2.2 is built against NumPy 1.x; the resolver installs NumPy 2.x on macOS/Windows (_ARRAY_API not found), so every encoder test that touches tensors fails.
2. ValueError: ...require torch to at least v2.6 (CVE-2025-32434) — the installed transformers refuses torch.load unless torch ≥ 2.6, so all SPLADE tests fail.

The contradiction is fatal: linux-3.9 can only resolve with torch < 2.3 (the triton → setuptools (py≥3.10) chain), but transformers demands torch ≥ 2.6. No single torch version satisfies both on Python 3.9. A torch cap cannot make this matrix cell green.

Recommendation: abandon the cap-torch approach and take issue #101 option 1 — drop Python 3.9 from the support matrix and CI. Python 3.9 reached end-of-life on 2025-10-31; the modern ML stack (transformers requiring torch≥2.6, NumPy 2.x) no longer supports it cleanly. That is a user-facing support-matrix change, so it needs maintainer/owner sign-off rather than being shipped from an autofix pass.

Converting this PR to draft so it isn't merged as-is. Tracking the decision on #101.

[jhamon]

Pushed 60ed922: the torch <2.3 cap resolved the dependency graph on Python 3.9 but surfaced a runtime failure in the macOS/Windows 3.9 cells — RuntimeError: Numpy is not available from SentenceTransformer.encode. torch 2.2.2 is built against the numpy 1.x ABI, and the unbounded numpy >=1.21.5 constraint let Poetry install numpy 2.x on 3.9.

Fix mirrors the torch split: cap numpy <2 on Python <3.10 (resolves to numpy 1.26.4), keep the open range on >=3.10 where torch >=2.3 supports numpy 2.x. Non-breaking.

Verified locally: poetry check → All set!; poetry lock now selects numpy 1.26.4 for the python<3.10 marker and 2.2.6 for >=3.10. Waiting on the 3.9 CI matrix to confirm green.

[jhamon]

Pushed 559b4d6 — third and final py3.9 dependency cap.

What the numpy fix (60ed922) surfaced: ubuntu 3.9 went green, but macos 3.9 and windows 3.9 now fail with:

ValueError: Due to a serious vulnerability issue in torch.load ... we now require users to upgrade torch to at least v2.6 (CVE-2025-32434)

Root cause: transformers >=4.49 gates torch.load behind torch >=2.6. Python 3.9 is capped at torch <2.3 (torch 2.2.2), so loading a SPLADE model that ships as pytorch_model.bin raises at import/load time. Ubuntu passed only because it happened to fetch a .safetensors variant (which bypasses torch.load); mac/win fell to the .bin path and hit the gate — i.e. the green ubuntu cell was non-deterministic luck, not a real pass.

Fix: cap transformers <4.49 on python <3.10, mirroring the existing torch/numpy split. This removes the gate entirely on 3.9, so the load is deterministic across all platforms.

Verified (not push-and-pray):

• transformers 4.48.3 has no torch≥2.6 gate; the CVE-2025-32434 gate first appears in 4.49.0 (confirmed by installing both wheels on py3.9.16 and grepping the source).
• poetry lock resolves cleanly: 4.48.3 for py<3.10 (with torch 2.2.2) and 4.57.6 for py>=3.10 (with torch 2.13.0).
• poetry check passes.

poetry.lock is gitignored here, so only pyproject.toml changed; CI regenerates the lock. CI re-run in flight.

[jhamon]

I think the correct thing to do here is actually to remove python 3.9 as it is EOL