build: drop speculative upper bounds on runtime and optional deps#114
Merged
Conversation
- Floor-only `torch`, `triton`, `pylate`, `colpali-engine` so downstream envs can resolve them freely; caps on a published wheel can't be overridden by installers and can conflict with torch's own triton pin - `patch_pylate()` / `patch_colpali_engine()` already no-op above the native-LIK cutoff, so no future major reaches the monkeypatched internals - Keep dev-tool caps (`pytest`, `ruff`, `ty`, `numpy`) — dev extras never reach downstream installers
865c78e to
09fb21e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
late-interaction-kernelsships a wheel, so it is a library, not just an internal app. Every dependency carried a<next-majorupper bound (torch<3,triton<4,pylate<2,colpali-engine<1). For a published library those caps are the well-documented anti-pattern: an installer cannot override them, so a downstream env that legitimately needstorch>=3becomes unsolvable even when our code would run fine. Reproducibility is already handled byuv.lock, which pins exact versions and hashes, so the caps add friction without adding safety.The one case that looked like it justified a cap was
pylateandcolpali-engine, sincepatch_pylate()/patch_colpali_engine()reach into those libraries' internals. But both patches already no-op above the native-LIK cutoff (pylate>=1.5.1,colpali-engine>=0.3.17), and any future major is by definition above that cutoff, so the patch steps aside before touching a single upstream symbol. The caps guard against breakage that cannot happen.The
triton<4cap was also actively harmful: torch pins the exact triton it needs, so our<4risks conflicting with a future torch that wants triton 4.Changes
Click here to expand
torch>=2.5(base,torch-cpu,torch-cuda) andtriton>=3.0, dropping the<3/<4caps.pylate>=1.3.3andcolpali-engine>=0.3.10, dropping<2/<1.numpy,pytest,ruff,tystay capped; thedevextra never reaches downstream installers, so its caps cause no resolution conflicts.0.4.5section documenting the loosened constraints.Note
uv lock --checkpasses. Theuv.lockdiff is only the loosenedrequires-distspecifiers; no pinned version actually changed.