Add support for `RUST_LOG` to the uv build backend. While we were
previously using logging statements in the uv build backend, they could
only be shown when when using the direct build fast path through uv, as
there was no tracing subscriber to write log messages out. This means no
debug logging when using the build backend through pip, `python -m
build`, an incompatible version of uv, or any other build frontend; No
option to figure why includes and excludes behave the way they do.
This PR closes this gap by adding a tracing subscriber. The only option
to enable it is `RUST_LOG`, as we don't have a CLI. The formatting style
is the same as for uv, and color is also support in the same way, albeit
only through anstream's support for TTYs and environment variables. We
recommend only `RUST_LOG=uv=debug` and `RUST_LOG=uv=verbose` in the
docs, but this can be used to debug into crates such as `glob`, too.
<img width="1008" height="325" alt="image"
src="https://github.com/user-attachments/assets/d33df219-750b-46a2-b3b4-8895aa137ab9"
/>
**Before**
```
$ pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
Running command pip subprocess to install build dependencies
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
Installing collected packages: uv_build
Successfully installed uv_build-0.8.13
Installing build dependencies ... done
Running command Getting requirements to build wheel
Getting requirements to build wheel ... done
Running command Preparing metadata (pyproject.toml)
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
Running command Building wheel for built-by-uv (pyproject.toml)
Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`
Caused by:
Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
error: subprocess-exited-with-error
× Building wheel for built-by-uv (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpow1illc9
cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
Building wheel for built-by-uv (pyproject.toml) ... error
ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```
**After**
```
$ RUST_LOG=uv=debug pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
Running command pip subprocess to install build dependencies
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
Installing collected packages: uv_build
Successfully installed uv_build-0.8.13
Installing build dependencies ... done
Running command Getting requirements to build wheel
Getting requirements to build wheel ... done
Running command Preparing metadata (pyproject.toml)
DEBUG Writing metadata files to /tmp/pip-modern-metadata-l_kh78cj
DEBUG Found PEP 639 license declarations, using METADATA 2.4
DEBUG License files match: `LICENSE-APACHE`
DEBUG License files match: `LICENSE-MIT`
DEBUG License files match: `third-party-licenses/PEP-401.txt`
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
Running command Building wheel for built-by-uv (pyproject.toml)
DEBUG Checking metadata directory /tmp/pip-modern-metadata-l_kh78cj/built_by_uv-0.1.0.dist-info
DEBUG Found PEP 639 license declarations, using METADATA 2.4
DEBUG License files match: `LICENSE-APACHE`
DEBUG License files match: `LICENSE-MIT`
DEBUG License files match: `third-party-licenses/PEP-401.txt`
DEBUG Writing wheel at /tmp/pip-wheel-bu6to9i7/built_by_uv-0.1.0-py3-none-any.whl
DEBUG Wheel excludes: ["__pycache__", "*.pyc", "*.pyo", "build-*!$§%!½¼²¼³¬!§%$§%.h", "/src/built_by_uv/not-packaged.txt"]
Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`
Caused by:
Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
error: subprocess-exited-with-error
× Building wheel for built-by-uv (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpjrxou13a
cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
Building wheel for built-by-uv (pyproject.toml) ... error
ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```
(There is no color in the above uv log statements, as pip doesn't
register as a TTY)
Fixes#12723
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
Update to the docs
## Test Plan
CI
Allows pinning the Python build version via environment variables, e.g.,
`UV_PYTHON_CPYTHON_BUILD=...`. Each variable is implementation specific,
because they use different versioning schemes.
Updates the Python download metadata to include a `build` string, so we
can filter downloads by the pin. Writes the build version to a file in
the managed install, e.g., `cpython-3.10.18-macos-aarch64-none/BUILD`,
so we can filter installed versions by the pin.
Some important follow-up here:
- Include the build version in not found errors (when pinned)
- Automatically use a remote list of Python downloads to satisfy build
versions not present in the latest embedded download metadata
Some less important follow-ups to consider:
- Allow using ranges for build version pins
## Summary
Move the Resolver reference into a new Internals section in the
reference. Add the new nav item, fix internal linking to the new path,
fix server side redirect to the new path for external traffic via
redirect_maps, fix non existent anchor in
"docs/concepts/projects/dependencies.md"
Closes#15412
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Closes#14866. Adds a `no-install-local` flag to the sync and export
commands that excludes locally defined packages from being installed.
This helps with if you're caching your virtual environment. You can
exclude local packages since they're more likely to change between
builds.
## Test Plan
snapshot test: `sync::no_install_local`
CI
## Notes
I made an `InstallOptions` struct to avoid a crate isolation issue I was
running into while implementing.
Thanks for maintaining this project!
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
i noticed some of the line highlights are wrong in the docs
## Test Plan
visual verification
## Summary
Add torch cuda 12.9 backend
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
---------
Signed-off-by: youkaichao <youkaichao@gmail.com>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
As a frontend to Ruff's formatter.
There are some interesting choices here, some of which may just be
temporary:
1. We pin a default version of Ruff, so `uv format` is stable for a
given uv version
2. We install Ruff from GitHub instead of PyPI, which means we don't
need a Python interpreter or environment
3. We do not read the Ruff version from the dependency tree
See https://github.com/astral-sh/ruff/pull/19665 for a prototype of the
LSP integration.
## Summary
Follow up to
https://github.com/astral-sh/uv/pull/15269#issuecomment-3194000772
Enables the following additional images to be published
* buildpack-deps:trixie
* debian:trixie-slim
* alpine:3.22
## Test Plan
Existing Tests. The newly added images were checked manually.
Correct typo. "uv cache clear" is not a command.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
## Summary
Split the cleanup fixes from https://github.com/astral-sh/uv/pull/15196
into a separate PR for easier review.
This cleans up some minor env var usage / references throughout tests
and runtime code.
## Test Plan
Existing Tests. No functional changes.
## Summary
It would be nice if this rendered as
`[tool.uv.extra-build-dependencies]` and `[extra-build-dependencies]`
(in `uv.toml`), but this is at least correct.
Closes https://github.com/astral-sh/uv/issues/15124.
As described in #15179, there are cases where it can be useful to
reinstall the latest patch on upgrade if it is already installed. Using
this flag, you don't need to know ahead of time if you have the latest
patch already.
Closes#15179.
Revives https://github.com/astral-sh/uv/pull/9130
Previously, we allowed scoping conflicting extras or groups to specific
packages, e.g. ,`{ package = "foo", extra = "bar" }` for a conflict in
`foo[bar]`. Now, we allow dropping the `extra` or `group` bit and using
`{ package = "foo" }` directly which declares a conflict with `foo`'s
production dependencies.
This means you can declare conflicts between workspace members, e.g.:
```
[tool.uv]
conflicts = [[{ package = "foo" }, { package = "bar" }]]
```
would not allow `foo` and `bar` to be installed at the same time.
Similarly, a conflict can be declared between a package and a group:
```
[tool.uv]
conflicts = [[{ package = "foo" }, { group = "lint" }]]
```
which would mean, e.g., that `--only-group lint` would be required for
the invocation.
As with our existing support for conflicting extras, there are
edge-cases here where the resolver will _not_ fail even if there are
conflicts that render a particular install target unusable. There's test
coverage for some of these. We'll still error at install-time when the
conflicting groups are selected. Due to the likelihood of bugs in this
feature, I've marked it as a preview feature.
I would not recommend reading the commits as there's some slop from not
wanting to rebase Andrew's branch.
---------
Co-authored-by: Andrew Gallant <andrew@astral.sh>
## Summary
uv will now reject ZIP files that meet any of the following conditions:
- Multiple local header entries exist for the same file with different
contents.
- A local header entry exists for a file that isn't included in the
end-of-central directory record.
- An entry exists in the end-of-central directory record that does not
have a corresponding local header.
- The ZIP file contains contents after the first end-of-central
directory record.
- The CRC32 doesn't match between the local file header and the
end-of-central directory record.
- The compressed size doesn't match between the local file header and
the end-of-central directory record.
- The uncompressed size doesn't match between the local file header and
the end-of-central directory record.
- The reported central directory offset (in the end-of-central-directory
header) does not match the actual offset.
- The reported ZIP64 end of central directory locator offset does not
match the actual offset.
We also validate the above for files with data descriptors, which we
previously ignored.
Wheels from the most recent releases of the top 15,000 packages on PyPI
have been confirmed to pass these checks, and PyPI will also reject ZIPs
under many of the same conditions (at upload time) in the future.
In rare cases, this validation can be disabled by setting
`UV_INSECURE_NO_ZIP_VALIDATION=1`. Any validations should be reported to
the uv issue tracker and to the upstream package maintainer.
Specifically, support `UV_NO_EDITABLE=1 uv export`. It's now also
supported in `uv add`, though it's default there anyway and the env var
exists only for completeness.
Fixes#15103
Close#6314
## Summary
Continuing from #7592. Created a new PR to rebase the old branch with
`main`, cleaned up test errors, and improved readability.
## Test Plan
Same test cases as in #7592.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Replaces https://github.com/astral-sh/uv/pull/14092
Adds `tool.uv.extra-build-dependencies = {package = [dependency, ...]}`
which extends `build-system.requires` during package builds.
These are lowered via workspace sources, are applied to transitive
dependencies, and are included in the wheel cache shard hash.
There are some features we need to follow-up on, but are out of scope
here:
- Preferring locked versions for build dependencies
- Settings for requiring locked versions for build depencies
There are some quality of life follow-ups we should also do:
- Warn on `extra-build-dependencies` that do not apply to any packages
- Add test cases and improve error messaging when the
`extra-build-dependencies` resolve fails
-------
There ~are~ were a few open decisions to be made here
1. Should we resolve these dependencies alongside the
`build-system.requires` dependencies? Or should we resolve separately?
(I think the latter is more powerful? because you can override things?
but it opens the door to breaking your build)
2. Should we install these dependencies into the same environment? Or
should we layer it on top as we do elsewhere? (I think it's fine to
install into the same environment)
3. Should we respect sources defined in the parent project? (I think
yes, but then we need to lower the dependencies earlier — I don't think
that's a big deal, but it's not implemented)
4. Should we respect sources defined in the child project? (I think no,
this gets really complicated and seems weird to allow)
5. Should we apply this to transitive dependencies? (I think so)
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
Co-authored-by: konstin <konstin@mailbox.org>
Adds `exclude-newer-package = { package = timestamp, ... } ` and
`--exclude-newer-package package=timestamp`. These take precedence over
`exclude-newer` for a given package.
This does need to be serialized to the lockfile, so the revision is
bumped to 3. I tested a previous version and we can read a lockfile with
this information just fine.
Closes https://github.com/astral-sh/uv/issues/14394
I think this would give us better hygiene than a global flag. It makes
it easier for users to opt-in to overlapping features, such as Python
upgrades and Python bin installations and to disable warnings for
preview mode without opting in to a bunch of other features. In general,
I want to reduce the burden for putting something under preview.
The `--preview` and `--no-preview` flags are retained as global
overrides. A new `--preview-features` option is added which accepts
comma separated features or can be passed multiple times, e.g.,
`--preview-features add-bounds,pylock`. There's a `UV_PREVIEW_FEATURES`
environment variable for that option (I'm not sure if we should overload
`UV_PREVIEW`, but could be convinced).
