5a95f50619
## Summary This PR adds limited support for PEP 440-compatible local version testing. Our behavior is _not_ comprehensively in-line with the spec. However, it does fix by _far_ the biggest practical limitation, and resolves all the issues that've been raised on uv related to local versions without introducing much complexity into the resolver, so it feels like a good tradeoff for me. I'll summarize the change here, but for more context, see [Andrew's write-up](https://github.com/astral-sh/uv/issues/1855#issuecomment-1967024866) in the linked issue. Local version identifiers are really tricky because of asymmetry. `==1.2.3` should allow `1.2.3+foo`, but `==1.2.3+foo` should not allow `1.2.3`. It's very hard to map them to PubGrub, because PubGrub doesn't think of things in terms of individual specifiers (unlike the PEP 440 spec) -- it only thinks in terms of ranges. Right now, resolving PyTorch and friends fails, because... - The user provides requirements like `torch==2.0.0+cu118` and `torchvision==0.15.1+cu118`. - We then match those exact versions. - We then look at the requirements of `torchvision==0.15.1+cu118`, which includes `torch==2.0.0`. - Under PEP 440, this is fine, because `torch @ 2.0.0+cu118` should be compatible with `torch==2.0.0`. - In our model, though, it's not, because these are different versions. If we change our comparison logic in various places to allow this, we risk breaking some fundamental assumptions of PubGrub around version continuity. - Thus, we fail to resolve, because we can't accept both `torch @ 2.0.0` and `torch @ 2.0.0+cu118`. As compared to the solutions we explored in https://github.com/astral-sh/uv/issues/1855#issuecomment-1967024866, at a high level, this approach differs in that we lie about the _dependencies_ of packages that rely on our local-version-using package, rather than lying about the versions that exist, or the version we're returning, etc. In short: - When users specify local versions upfront, we keep track of them. So, above, we'd take note of `torch` and `torchvision`. - When we convert the dependencies of a package to PubGrub ranges, we check if the requirement matches `torch` or `torchvision`. If it's an`==`, we check if it matches (in the above example) for `torch==2.0.0`. If so, we _change_ the requirement to `torch==2.0.0+cu118`. (If it's `==` some other version, we return an incompatibility.) In other words, we selectively override the declared dependencies by making them _more specific_ if a compatible local version was specified upfront. The net effect here is that the motivating PyTorch resolutions all work. And, in general, transitive local versions work as expected. The thing that still _doesn't_ work is: imagine if there were _only_ local versions of `torch` available. Like, `torch @ 2.0.0` didn't exist, but `torch @ 2.0.0+cpu` did, and `torch @ 2.0.0+gpu` did, and so on. `pip install torch==2.0.0` would arbitrarily choose one one `2.0.0+cpu` or `2.0.0+gpu`, and that's correct as per PEP 440 (local version segments should be completely ignored on `torch==2.0.0`). However, uv would fail to identify a compatible version. I'd _probably_ prefer to fix this, although candidly I think our behavior is _ok_ in practice, and it's never been reported as an issue. Closes https://github.com/astral-sh/uv/issues/1855. Closes https://github.com/astral-sh/uv/issues/2080. Closes https://github.com/astral-sh/uv/issues/2328. |
||
|---|---|---|
| .. | ||
| bench | ||
| cache-key | ||
| distribution-filename | ||
| distribution-types | ||
| install-wheel-rs | ||
| once-map | ||
| pep440-rs | ||
| pep508-rs | ||
| platform-tags | ||
| pypi-types | ||
| requirements-txt | ||
| uv | ||
| uv-auth | ||
| uv-build | ||
| uv-cache | ||
| uv-client | ||
| uv-dev | ||
| uv-dispatch | ||
| uv-distribution | ||
| uv-extract | ||
| uv-fs | ||
| uv-git | ||
| uv-installer | ||
| uv-interpreter | ||
| uv-normalize | ||
| uv-resolver | ||
| uv-traits | ||
| uv-trampoline | ||
| uv-version | ||
| uv-virtualenv | ||
| uv-warnings | ||
| README.md | ||
Crates
bench
Functionality for benchmarking uv.
cache-key
Generic functionality for caching paths, URLs, and other resources across platforms.
distribution-filename
Parse built distribution (wheel) and source distribution (sdist) filenames to extract structured metadata.
distribution-types
Abstractions for representing built distributions (wheels) and source distributions (sdists), and the sources from which they can be downloaded.
install-wheel-rs
Install built distributions (wheels) into a virtual environment.]
once-map
A waitmap-like concurrent hash map for executing tasks
exactly once.
pep440-rs
Utilities for interacting with Python version numbers and specifiers.
pep508-rs
Utilities for interacting with PEP 508 dependency specifiers.
platform-host
Functionality for detecting the current platform (operating system, architecture, etc.).
platform-tags
Functionality for parsing and inferring Python platform tags as per PEP 425.
uv
Command-line interface for the uv package manager.
uv-build
A PEP 517-compatible build frontend for uv.
uv-cache
Functionality for caching Python packages and associated metadata.
uv-client
Client for interacting with PyPI-compatible HTTP APIs.
uv-dev
Development utilities for uv.
uv-dispatch
A centralized struct for resolving and building source distributions in isolated environments.
Implements the traits defined in uv-traits.
uv-distribution
Client for interacting with built distributions (wheels) and source distributions (sdists). Capable of fetching metadata, distribution contents, etc.
uv-extract
Utilities for extracting files from archives.
uv-fs
Utilities for interacting with the filesystem.
uv-git
Functionality for interacting with Git repositories.
uv-installer
Functionality for installing Python packages into a virtual environment.
uv-interpreter
Functionality for detecting and leveraging the current Python interpreter.
uv-normalize
Normalize package and extra names as per Python specifications.
uv-package
Types and functionality for working with Python packages, e.g., parsing wheel files.
uv-resolver
Functionality for resolving Python packages and their dependencies.
uv-traits
Shared traits for uv, to avoid circular dependencies.
pypi-types
General-purpose type definitions for types used in PyPI-compatible APIs.
uv-virtualenv
A venv replacement to create virtual environments in Rust.
uv-warnings
User-facing warnings for uv.
requirements-txt
Functionality for parsing requirements.txt files.