fix!: bump seqpro to 0.22.0 for per-variant allele indexing (#330)

[d-laub]

Closes #330. Upstream fix: ML4GLand/SeqPro#71, released in seqpro 0.22.0.

What was wrong

RaggedVariants.alt[i] / ref[i] returned one concatenated bytes per haplotype while start / ilen returned per-variant values, even though all four fields share one offsets object. zip(rv.start[0][h], rv.alt[0][h]) was silently wrong — and invisible for SNP-only data, because 1-byte alleles make the counts coincide. It only misbehaved once an indel entered the window.

Root cause was upstream: seqpro's Ragged.__getitem__ mapped a string-under-axis group straight to a byte range and discarded the interior str_offsets.

Changes

• pyproject.toml: seqpro>=0.20 → seqpro>=0.22
• pixi.toml: py310 pin ==0.21.1 → ==0.22.0
• pixi.lock regenerated
• New regression test using a multi-byte allele — the existing suite asserts via to_ak().to_list(), which is structure-preserving and was blind to this
• SKILL.md + docs/source/dataset.md document per-variant allele access and the seqpro>=0.22 requirement

Cargo.toml is untouched: the 0.22.0 diff changed no Rust, so seqpro-core needs no bump.

Raising the floor also forecloses a latent skew — py311/312/313 declare no seqpro pin and inherit the floor, so now that genoray's cap is lifted a lock refresh under >=0.20 would float them to 0.22 while py310 stayed pinned at 0.21.

Also raises the genoray floor to >=3.3.1

Every genoray up to 3.3.0 pinned seqpro>=0.21.1,<0.22, which made seqpro>=0.22 unsolvable. That cap was lifted to <0.23 in d-laub/genoray#142 and released as genoray 3.3.1, so pixi.lock here moves genoray 3.0.0 → 3.3.1.

genoray>=3.0.0,<4 was not wrong — because seqpro>=0.22 is a direct top-level constraint, pip/uv/pixi all reject the older genoray releases themselves rather than resolving to something broken. But they report it as a transitive seqpro conflict, which points away from the actual requirement. So the floor is now declared directly, in both pyproject.toml and pixi.toml (the py310 feature mirrors the pyproject floor).

Resolution is unchanged: the lock already selected genoray 3.3.1, and the only lock delta is the recorded requires-dist line. This changes the error message users get, not what they install.

Breaking

Indexing an allele field by integer now yields per-variant alleles instead of one concatenated bytes. Callers wanting the old value can use b"".join(...). major_version_zero = true, so this cuts 0.40.2 → 0.41.0.

Verification

Full suite on a dedicated SLURM allocation (32 CPUs), against the real solved environment (seqpro 0.22.0 + genoray 3.3.1), no deselections:

1110 passed, 56 skipped, 4 xfailed in 365.79s (0:06:05)

1110 + 56 + 4 = 1170 — the full collected count. Also green: cargo test --release (138 passed), pyrefly (0 errors), ruff check / ruff format --check, the api.md-vs-__all__ gate, a clean sphinx-build, and cz check over the branch (so the BREAKING CHANGE: footer is machine-readable and the bump lands as a minor, not a patch).

The regression test was confirmed RED on seqpro 0.21.1 before the bump (list(rv.alt[0][0]) yielded [65, 71, 71] — ints from iterating a bytes blob — instead of [b"A", b"GG"]) and GREEN after.

An audit of the six string-Ragged consumers found that all of them only construct string Raggeds or read fields by name / _rl.str_offsets / .to_chars(), none of which changed in 0.22.0. grep -rnE "\.(alt|ref)\[[0-9a-z_]" python/genvarloader/ returns zero hits, so nothing in the package ever depended on the old concatenating behavior.

Not included

Targets main, not streaming — the defect is in the shared RaggedVariants read path the written Dataset returns too. streaming inherits the fix on its next routine main merge.

🤖 Generated with Claude Code