release: v0.4.2 — republish the stack to close the PyPI version skew

[theGreatHerrLebert]

Why

A user installed current imspy-simulation on a VM and timsim died at import:

AttributeError: module 'imspy_connector' has no attribute 'py_acquisition'

imspy-connector on PyPI is 0.4.1, uploaded 2026-02-06 — the same day as the v0.4.0 tag. main's Cargo.toml also says 0.4.1, but the crate is 108 commits ahead of that wheel and has since gained an entire submodule, py_acquisition. Same version number, seven months of different content.

The import chain that breaks:

simulator.py:98             from .jobs.dda_selection_scheme import ...
dda_selection_scheme.py:13  ims_acquisition = imspy_connector.py_acquisition   # module level, unguarded

Nothing is wrong with how he installed it. The published connector is simply stale.

What's in this release

Package	PyPI now	Uploaded	Drift	→
imspy-connector	0.4.1	Feb 6	108 Rust commits, new py_acquisition	0.4.2
imspy-simulation	0.4.1	Feb 6	82 commits	0.4.2 (#453)
imspy-predictors	0.5.1	Feb 13	19 commits, incl. the #452 Prosit/Koina fix	0.5.2
imspy-core	0.4.1	Jul 28	1 commit	0.4.2
imspy-search	0.4.0	Feb 6	1 commit	0.4.1
imspy-vis	0.4.0	Feb 6	7 commits	0.4.1
imspy-dia	0.4.0	Feb 6	none	unchanged

Two traps this had to clear

1. The connector version is declared twice. imspy_connector/pyproject.toml carries its own version, and maturin takes the wheel version from there, not from Cargo.toml. Bumping only Cargo.toml compiles v0.4.2 and emits an 0.4.1 wheel — which PyPI rejects as a duplicate, so maturin publish fails and the release ships nothing while looking like it worked. Caught by building the wheel locally; both files are bumped.

2. The pins were too loose to force the upgrade. imspy-core asked for imspy-connector>=0.3.0, imspy-dia for >=0.4.0. An existing environment would upgrade everything else and keep its stale connector — reproducing the exact break. All pins now require the versions in this release.

imspy-simulation also gains an explicit imspy-connector>=0.4.2 dependency. It imports imspy_connector directly in writers.py, acquisition.py and timsim/jobs/*, but only ever received it transitively through imspy-core — that undeclared dependency is what let the skew go unnoticed in the first place.

imspy-dia has no code changes, so it stays at 0.4.0; its pins are fixed on main and ship with its next release.

Verification

Built and exercised the exact artifacts this release would publish, in a clean environment:

• Connector wheel built with the CI invocation (maturin build --release, no --features). thermorawfile/sciexwiff are optional feature-gated deps, so no private-repo access is needed — confirmed by the build succeeding without it.
• All six Python wheels built; Requires-Dist metadata inspected in each — every path to imspy-simulation now forces imspy-connector>=0.4.2.
• Installed into a fresh venv and ran the failing chain end to end:

all submodules present: True
py_acquisition OK: PyAcquisitionScheme | has_thermo: False | has_mzml: False
dda_selection_scheme import: OK  <-- this is what raised AttributeError
timsim simulator import: OK
lock guard shipped: True | reuse guard: True
timsim --help → exit 0

• imspy-simulation suite against the installed wheels: 146 passed, 15 skipped, 1 failed.

The one failure, test_template_acquisition_common.py::test_rt_cycle_length_raises_on_single_ms1, is pre-existing on main — both the test and template_acquisition_common.py are byte-identical to main in this branch, and it dates to f465dbc6 (the build-from-template schedule gate), where an earlier validate_template_schedule check now fires before the one the test asserts on. It went unnoticed because no CI workflow runs the Python tests — only rust.yml does, and only for the crates. Worth fixing separately; flagging it rather than folding it into a release PR.

Release mechanics

Both imspy-connector-publish.yml and imspy-publish.yml trigger on release: published, so one GitHub release ships the connector wheels (ubuntu/windows/macos-14/macos-15 × py3.11–3.13) and all Python packages.

This PR contains no code changes — only version strings, dependency pins, and the version tables in CLAUDE.md.

https://claude.ai/code/session_01532ckxwR1fUorKF7CN66uA