Skip to content

Conversation

senokay
Copy link

@senokay senokay commented Jul 10, 2025

Torch is frequently installed with a local version identifier (e.g. +cu126), but that identifier causes an issue with pip because there is no public package with that identifier unless an explicit alternative index is used. The issue also happens to come with a quite cryptic ResolutionImpossible error (pypa/pip#13422) which completely obscures the actual issue.

Stripping the local version identifier should be safe, as we are only using constraints to ensure that per-model dependencies are aligned with existing installations.

Fun anecdote: Gemini was extensively used to discover the underlying issue. Full transcript here.

Torch is frequently installed with a local version identifier (e.g.
`+cu126`), but that identifier causes an issue with pip because there is
no public package with that identifier unless an explicit alternative
index is used. Stripping the local version identifier should be safe, as
we are only using constraints to ensure that per-model dependencies are
aligned with existing installations.
@senokay senokay force-pushed the ignore-local-version-in-constraints branch from 0a2f22d to c819823 Compare September 2, 2025 06:53
@senokay senokay temporarily deployed to docker-s3-upload September 5, 2025 20:30 — with GitHub Actions Inactive
@senokay senokay temporarily deployed to docker-s3-upload September 5, 2025 20:30 — with GitHub Actions Inactive
@xuzhao9
Copy link
Contributor

xuzhao9 commented Sep 5, 2025

This is a bit weird because we test on pytorch nightly, where the version is like 2.8.0.dev20250606+cu128, so I thought pip can correctly handle version suffix like +cu128...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants