Dependency proposal: hyalite for the CellRanger4 TSO clip

[BenjaminDEMAILLE]

Per CONTRIBUTING.md ("New dependencies need prior discussion"), raising this before opening a PR.

What needs it

--clipAdapterType CellRanger4 has two trims. #148 implements the 3' poly-A trim, which is scalar arithmetic. The 5' TSO trim is an overlap alignment of the template-switch oligo against the first 91 bases of the read, which STAR performs by linking Opal. That trim is the reason --clipAdapterType CellRanger4 is currently incomplete.

Proposal

hyalite (@Psy-Fer), as an optional dependency behind an off-by-default feature.

It fits the requirement exactly: overlap mode with affine gaps, ScoreEnd search, and a bit-identical-across-backends guarantee, which is what makes it usable here — the clip length feeds a coordinate, so a result that depends on which SIMD backend the CPU offers would make output machine-dependent. Its own benchmark is a CellRanger4-shaped overlap scan.

The parameters STAR uses (ClipCR4.cpp): match +1, mismatch -2, N-against-N 0, gap open and extend 2, target padded to 91 bases with N, OPAL_MODE_OV with OPAL_SEARCH_SCORE_END. All expressible through hyalite::Scoring and align_pair.

What needs deciding

It is not on crates.io yet. A git dependency blocks cargo publish, so the feature cannot be enabled in a published build until hyalite is released. Options, in the order I would rank them:

1. Wait for a crates.io release, then add it as an optional dependency and finish the TSO trim.
2. Add it now as an optional git dependency behind an off-by-default feature, and switch the source to crates.io when it is published. The default build and the published crate are unaffected either way, but the manifest carries a git URL in the meantime.
3. Leave --clipAdapterType CellRanger4 doing only the poly-A trim, warning that the TSO trim is not applied.

Currently option 3 is what #148 does.

The dependency itself is pure Rust with no build-time C, no bindgen, and no system library, so it does not carry the supply-chain weight the CONTRIBUTING rule is mainly aimed at. The open question is timing and the git-source constraint, not the dependency's nature.

Happy to prepare the integration against whichever option you prefer.

[Psy-Fer]

I literally only made hyalite public ~1h ago. I'm still doing the release, while I pedantically check everything.

I will handle the connection to hyalite, because there might be issues that need to be resolved on the hyalite side, and i will be able to patch them quickly during development. That should remove any overall issues.

the clip length feeds a coordinate, so a result that depends on which SIMD backend the CPU offers would make output machine-dependent

This isn't true, and was baked into the design of hyalite from the beginning. No matter what backend you use, you will ALWAYS get the same result, as long as:

• It is run on the same input
• it isn't compiled with something like -C target-cpu=native on a newer CPU then runs it on an older CPU

That was kind of the point in writing it, and not claiming that it is byte identical to Opal, because Opal had issues, which I fixed in hyalite. There is a reason I say this in the README:

Exact, SIMD-accelerated pairwise and database sequence alignment in pure Rust. Smith-Waterman (local), Needleman-Wunsch (global), semi-global, and overlap modes with affine gaps, runtime CPU dispatch, and a bit-identical-across-backends guarantee.

James

[BenjaminDEMAILLE]

Understood — hyalite is yours to wire in.

On the quoted line: I was arguing for hyalite, not against it. The sentence was meant as "backend-dependent output would be disqualifying here, and hyalite guarantees it isn't" — the guarantee is the reason I proposed it rather than something scalar. It reads as a doubt about hyalite, which is not what I meant. My wording.

Leaving #148 as the poly-A trim only, with --clipAdapterType CellRanger4 warning that the TSO trim is not applied, so nothing here blocks or pre-empts your integration.