Allow users to pre-define dependency metadata #7393
Comments
charliermarsh
added
the
enhancement
|
I planned to file this issue separately, haha. (but I temporarily left my laptop until now) #7291 |
|
Yeah this would at least make it possible to |
|
I think this should be beyond the direct dependency of the user's project. It should act as hand-crafted resolution rules. |
|
Yeah I think this should be "allowed" for any dependency. |
|
Does this override existing metadata or only get used when not available? I'm a little so-so on the naming because it collides with general dependency groups but otherwise it sounds cool. |
|
I think it would override... It would also allow you to (e.g.) remove dependencies unlike |
|
(I agree |
## Summary This PR enables users to provide pre-defined static metadata for dependencies. It's intended for situations in which the user depends on a package that does _not_ declare static metadata (e.g., a `setup.py`-only sdist), and that is expensive to build or even cannot be built on some architectures. For example, you might have a Linux-only dependency that can't be built on ARM -- but we need to build that package in order to generate the lockfile. By providing static metadata, the user can instruct uv to avoid building that package at all. For example, to override all `anyio` versions: ```toml [project] name = "project" version = "0.1.0" requires-python = ">=3.12" dependencies = ["anyio"] [[tool.uv.dependency-metadata]] name = "anyio" requires-dist = ["iniconfig"] ``` Or, to override a specific version: ```toml [project] name = "project" version = "0.1.0" requires-python = ">=3.12" dependencies = ["anyio"] [[tool.uv.dependency-metadata]] name = "anyio" version = "3.7.0" requires-dist = ["iniconfig"] ``` The current implementation uses `Metadata23` directly, so we adhere to the exact schema expected internally and defined by the standards. Any entries are treated similarly to overrides, in that we won't even look for `anyio@3.7.0` metadata in the above example. (In a way, this also enables #4422, since you could remove a dependency for a specific package, though it's probably too unwieldy to use in practice, since you'd need to redefine the _rest_ of the metadata, and do that for every package that requires the package you want to omit.) This is under-documented, since I want to get feedback on the core ideas and names involved. Closes #7393.
For packages that don't declare static metadata, it can be a pain to require building the package just to resolve. For example, you might have a dependency that can't be built on ARM, but doesn't declare static metadata. In that case, users can't resolve on ARM, even if the dependency is never installed on ARM (i.e., it has an environment marker).
I think it'd be neat to allow users to define static metadata for their dependencies as an escape hatch, like:
The text was updated successfully, but these errors were encountered: