Commit Graph

1031 Commits

Author SHA1 Message Date
Charlie Marsh b81cce9152
Support `extras` and `dependency_groups` markers on `uv pip install` and `uv pip sync` (#14755)
## Summary

We don't yet support writing these, but we can at least read them
(which, e.g., allows you to install PDM-exported `pylock.toml` files
with uv, since PDM _always_ writes a default group).

Closes #14740.
2025-07-21 12:48:47 +00:00
Charlie Marsh fcf0bdd3a6
Add missing `the` in concept link (#14763) 2025-07-20 17:38:24 -04:00
Matt Norton d85a300b5f
Fix typo in `concepts/projects/config.md` (#14759) 2025-07-20 17:27:33 -04:00
Charlie Marsh 9c9db9b547
Clarify which portions of requires-python behavior are consistent with pip (#14752)
See: #14711
2025-07-20 09:44:25 -04:00
Charlie Marsh e724ddc63f
Allow `--config-settings-package` to apply configuration settings at the package level (#14573)
## Summary

Closes https://github.com/astral-sh/uv/issues/14564.

Closes https://github.com/astral-sh/uv/issues/10940.
2025-07-17 21:27:54 -04:00
Zanie Blue 1a339b76e8 Add release notes and bump version for 0.8.0 (#14690)
[Rendered](https://github.com/astral-sh/uv/blob/zb/release-notes/CHANGELOG.md)
2025-07-17 17:20:21 -05:00
Zanie Blue cd40a34522 Build and install workspace members that are dependencies by default (#14663)
Regardless of the presence of a build system, as in
https://github.com/astral-sh/uv/pull/14413

---------

Co-authored-by: John Mumm <jtfmumm@gmail.com>
2025-07-17 17:20:21 -05:00
Zanie Blue 0077f2357f Stabilize addition of Python executables to the bin (#14626)
Closes https://github.com/astral-sh/uv/issues/14296

As mentioned in #14681, this does not stabilize the `--default`
behavior.
2025-07-17 17:20:21 -05:00
John Mumm ff30f14d50 Build `path` sources without build systems by default (#14413)
We currently treat path sources as virtual if they do not specify a
build system, which is surprising behavior. This PR updates the behavior
to treat path sources as packages unless the path source is explicitly
marked as `package = false` or its own `tool.uv.package` is set to
`false`.

Closes #12015

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-17 17:20:21 -05:00
John Mumm 2df06ebfbc Require `uv venv --clear` before removing an existing directory (#14309)
By default, `uv venv <venv-name>` currently removes the `<venv-name`>
directory if it exists. This can be surprising behavior: not everyone
expects an existing environment to be overwritten. This PR updates the
default to fail if a non-empty `<venv-name>` directory already exists
and neither `--allow-existing` nor the new `-c/--clear` option is
provided (if a TTY is detected, it prompts first). If it's not a TTY,
then uv will only warn and not fail for now — we'll make this an error
in the future. I've also added a corresponding `UV_VENV_CLEAR` env var.

I've chosen to use `--clear` instead of `--force` for this option
because it is used by the `venv` module and `virtualenv` and will be
familiar to users. I also think its meaning is clearer in this context
than `--force` (which could plausibly mean force overwrite just the
virtual environment files, which is what our current `--allow-existing`
option does).

Closes #1472.

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-17 17:20:21 -05:00
Zanie Blue 25e69458b1 Stabilize addition of Python versions to the Windows registry (#14625)
Following #14614 this is non-fatal and has an opt-out so it should be
safe to stabilize.
2025-07-17 17:20:21 -05:00
konsti 3c9aea87b4 `uv init`: Make `uv_build` the default build backend (from `hatchling`) (#14661)
Closes https://github.com/astral-sh/uv/issues/14298

Switch the default build backend for `uv init` from `hatchling` to
`uv_build`.

This change affects the following two commands:

* `uv init --lib`
* `uv init [--app] --package`

It does not affect `uv init` or `uv init --app` without `--package`. `uv
init --build-backend <...>` also works as before.

**Before**

```
$ uv init --lib project
$ cat project/pyproject.toml
[project]
name = "project"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
authors = [
    { name = "konstin", email = "konstin@mailbox.org" }
]
requires-python = ">=3.13.2"
dependencies = []

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
```

**After**

```
$ uv init --lib project
$ cat project/pyproject.toml
[project]
name = "project"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
authors = [
    { name = "konstin", email = "konstin@mailbox.org" }
]
requires-python = ">=3.13.2"
dependencies = []

[build-system]
requires = ["uv_build>=0.7.20,<0.8"]
build-backend = "uv_build"
```

I cleaned up some tests for consistency in the second commit.
2025-07-17 17:20:21 -05:00
Charlie Marsh c3d7d3899c Default to `--workspace` when adding subdirectories (#14529)
If `--workspace` is provided, we add all paths as workspace members.

If `--no-workspace` is provided, we add all paths as direct path
dependencies.

If neither is provided, then we add any paths that are under the
workspace root as workspace members, and the rest as direct path
dependencies.

Closes #14524.
2025-07-17 17:20:21 -05:00
Charlie Marsh e4c04af32d Bump `--python-platform linux` to `manylinux_2_28` (#14300)
Right now, `--python-platform linux` to defaults to `manylinux_2_17`.
Defaulting to `manylinux_2_17` causes some problems for users, since it
means we can't use (e.g.) `manylinux_2_28` wheels, and end up having to
build from source.

cibuildwheel made `manylinux_2_28` their default in
https://github.com/pypa/cibuildwheel/pull/1988, and there's a lot of
discussion in https://github.com/pypa/cibuildwheel/issues/1772 and
https://github.com/pypa/cibuildwheel/issues/2047. In short, the
`manylinux_2014` image is EOL, and the vast majority of consumers now
run at least glibc 2.28 (https://mayeut.github.io/manylinux-timeline/):

![Screenshot 2025-06-26 at 7 47
23 PM](https://github.com/user-attachments/assets/2672d91b-f9eb-4442-b680-7e4cd7cade91)

Note that this only changes the _default_. Users can still compile
against `manylinux_2_17` by specifying it.
2025-07-17 17:20:21 -05:00
samypr100 35e2f67b5e feat(docker): set default `UV_TOOL_BIN_DIR` on docker images (#13391)
Closes #13057

Sets `UV_TOOL_BIN_DIR` to `/usr/local/bin` for all derived images to
allow `uv tool install` to work out of the box.

Note, when the default image user is overwritten (e.g. `USER <UID>`) by
a less privileged one, an alternative writable location would now need
to be set by downstream consumers to prevent issues, hence I'm labeling
this as a breaking change for 0.8.x release.

Relates to https://github.com/astral-sh/uv-docker-example/pull/55

Each image was tested to work with uv tool with `UV_TOOL_BIN_DIR` set to
`/usr/local/bin` with the default root user and alternative non-root
users to confirm breaking nature of the change.
2025-07-17 17:20:21 -05:00
Zanie Blue 868ecd7b3a
Add support for toggling Python bin and registry install options via env vars (#14662)
Adds environment variables for
https://github.com/astral-sh/uv/pull/14612 and
https://github.com/astral-sh/uv/pull/14614

We can't use the Clap `BoolishValueParser` here, and the reasoning is a
little hard to explain. If we used `UV_PYTHON_INSTALL_NO_BIN`, as is our
typical pattern, it'd work, but here we allow opt-in to hard errors with
`UV_PYTHON_INSTALL_BIN=1` and I don't think we should have both
`UV_PYTHON_INSTALL_BIN` and `UV_PYTHON_INSTALL_NO_BIN`.

Consequently, this pull request introduces a new `EnvironmentOptions`
abstraction which allows us to express semantics that Clap cannot —
which we probably want anyway because we have an increasing number of
environment variables we're parsing downstream, e.g., #14544 and #14369.
2025-07-17 12:33:43 -05:00
Zanie Blue 78d6d1134a
Bump version to 0.7.22 (#14685) 2025-07-17 11:27:15 -05:00
adisbladis bdb8c2646a
Add UV_COMPILE_BYTECODE_TIMEOUT environment variable (#14369)
## Summary

When installing packages on _very_ slow/overloaded systems it'spossible
to trigger bytecode compilation timeouts, which tends to happen in
environments such as Qemu (especially without KVM/virtio), but also on
systems that are simply overloaded. I've seen this in my Nix builds if I
for example am compiling a Linux kernel at the same time as a few other
concurrent builds.

By making the bytecode compilation timeout adjustable you can work
around such issues. I plan to set `UV_COMPILE_BYTECODE_TIMEOUT=0` in the
[pyproject.nix
builders](https://pyproject-nix.github.io/pyproject.nix/build.html) to
make them more reliable.

- Related issues

  * https://github.com/astral-sh/uv/issues/6105

## Test Plan

Only manual testing was applied in this instance. There is no existing
automated tests for bytecode compilation timeout afaict.
2025-07-17 08:11:32 -05:00
Charlie Marsh 7cdc1f62ee
Suggest `uv cache clean` prior to `--reinstall` (#14659)
## Summary

Closes https://github.com/astral-sh/uv/issues/14479.
2025-07-16 12:02:29 -04:00
Nathan Cain e547527587
Add UV_LIBC to allow libc selection in multi-libc environment (#14646)
Closes #14262 

## Description

Adds `UV_LIBC` environment variable and implements check within
`Libc::from_env` as recommended here:
https://github.com/astral-sh/uv/issues/14262#issuecomment-3014600313

Gave this a few passes to make sure I follow dev practices within uv as
best I am able. Feel free to call out anything that could be improved.

## Test Plan

Planned to simply run existing test suite. Open to adding more tests
once implementation is validated due to my limited Rust experience.
2025-07-16 08:52:17 -05:00
Gilles Peiffer 861f7a1c42
docs: add missing backtick (#14654)
Subject is message :)
2025-07-16 13:44:29 +00:00
Zanie Blue 8d6d0678a7
Move "Conflicting dependencies" to the "Resolution" page (#14633) 2025-07-15 16:47:43 -05:00
Zanie Blue ab2bd0179b
Mention the `revision` in the lockfile versioning doc (#14634) 2025-07-15 14:35:54 -05:00
Zanie Blue d525720266
Add `uv python update-shell` (#14627)
Part of #14296 

This is the same as `uv tool update-shell` but handles the case where
the Python bin directory is configured to a different path.

```
❯ UV_PYTHON_BIN_DIR=/tmp/foo cargo run -q -- python install --preview 3.13.3
Installed Python 3.13.3 in 1.75s
 + cpython-3.13.3-macos-aarch64-none
warning: `/tmp/foo` is not on your PATH. To use installed Python executables, run `export PATH="/tmp/foo:$PATH"` or `uv python update-shell`.
❯ UV_PYTHON_BIN_DIR=/tmp/foo cargo run -q -- python update-shell
Created configuration file: /Users/zb/.zshenv
Restart your shell to apply changes
❯ cat /Users/zb/.zshenv
# uv
export PATH="/tmp/foo:$PATH"
❯ UV_TOOL_BIN_DIR=/tmp/bar cargo run -q -- tool update-shell
Updated configuration file: /Users/zb/.zshenv
Restart your shell to apply changes
❯ cat /Users/zb/.zshenv
# uv
export PATH="/tmp/foo:$PATH"

# uv
export PATH="/tmp/bar:$PATH"
```
2025-07-15 13:47:02 -05:00
Zanie Blue c226d66f35
Rename "Dependency specifiers" section to exclude PEP 508 reference (#14631) 2025-07-15 12:55:57 -05:00
Zanie Blue d2c81e503f
Make preview Python registration on Windows non-fatal (#14614)
Same as #14612 for registration with the Windows Registry.
2025-07-15 17:29:11 +00:00
Zanie Blue bb1e9a247c
Update preview installation of Python executables to be non-fatal (#14612)
Previously, if installation of executables into the bin directory failed
we'd with a non-zero code. However, if we make this behavior the default
we don't want it to be fatal. There's a `--bin` opt-in to _require_
successful executable installation and a `--no-bin` opt-out to silence
the warning / opt-out of installation entirely.

Part of https://github.com/astral-sh/uv/issues/14296 — we need this
before we can stabilize the behavior.

In #14614 we do the same for writing entries to the Windows registry.
2025-07-15 17:12:36 +00:00
Charlie Marsh 405ef66cef
Allow users to override index `cache-control` headers (#14620)
## Summary

You can now override the cache control headers for the Simple API, file
downloads, or both:

```toml
[[tool.uv.index]]
name = "example"
url = "https://example.com/simple"
cache-control = { api = "max-age=600", files = "max-age=365000000, immutable" }
```

Closes https://github.com/astral-sh/uv/issues/10444.
2025-07-15 10:00:04 -04:00
InSync b046e7f3be
Add missing comma in `projects/dependencies.md` (#14613)
## Summary

Diff:

```diff
 [dependency-groups]
 dev = [
-  {include-group = "lint"}
+  {include-group = "lint"},
   {include-group = "test"}
 ]
```

## Test Plan

None.
2025-07-14 14:06:05 -05:00
Geoffrey Thomas 77c771c7f3
Bump version to 0.7.21 (#14611) 2025-07-14 14:01:28 -04:00
Aria Desires 34fbc06ad6
Add experimental `uv sync --output-format json` (#13689)
This is a continuation of the work in 

* #12405 

I have:
* moved to an architecture where the human output is derived from the
json structs to centralize more of the printing state/logic
* cleaned up some of the names/types
* added tests
* removed the restriction that this output is --dry-run only

I have not yet added package info, which was TBD in their design.

---------

Co-authored-by: x0rw <mahdi.svt5@gmail.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Co-authored-by: John Mumm <jtfmumm@gmail.com>
2025-07-14 14:53:39 +00:00
Zanie Blue 71470b7b1a
Add `UV_HTTP_RETRIES` to customize retry counts (#14544)
I want to increase this number in CI and was surprised we didn't support
configuration yet.
2025-07-11 07:35:27 -05:00
Charlie Marsh 2e0f399eeb
Run `cargo dev generate-all` (#14555)
## Summary

I think we had a missing rebase.
2025-07-11 01:46:44 +00:00
Charlie Marsh cc5d5d5fba
Fix repeated word in Pyodide doc (#14554) 2025-07-11 01:41:32 +00:00
Charlie Marsh 0fb8c2b1d7
Add `--python-platform` to `uv sync` (#14320)
## Summary

Closes https://github.com/astral-sh/uv/issues/14273.
2025-07-11 01:38:28 +00:00
Noam Teyssier 43dbdba578
feature: shorthand for --with (-w) in uvx and uv tool run (#14530)
<!--
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

This is a small quality of life feature that adds a shorthand (`-w`) to
the `--with` flag for minimizing keystrokes.

Pretty minor, but I didn't see any conflicts with `-w` and thought this
could be a nice place for it.

```bash
# proposed addition (short)
uvx -w numpy ipython

# original (long)
uvx --with numpy ipython
```

## Test Plan

Added testing already in the P.R. - just copied over tests from the
`--with` flag

<!-- How was it tested? -->
2025-07-10 13:50:50 -05:00
Aria Desires 042df4a7de
Expand the functionality of `uv version --bump` to support pre-releases (#13578)
This adds `alpha`, `beta`, `rc`, `stable`, `post`, and `dev` modes to
`uv version --bump`.

The components that `--bump` accepts are ordered as follows:

    major > minor > patch > stable > alpha > beta > rc > post > dev
    
Bumping a component "clears" all lesser component (`alpha`, `beta`, and
`rc` all overwrite each other):

* `--bump minor` on `1.2.3a4.post5.dev6` => `1.3.0`
* `--bump alpha` on `1.2.3a4.post5.dev6` => `1.2.3a5` 
* `--bump dev  ` on `1.2.3a4.post5.dev6` => `1.2.3a4.post5.dev7`

In addition, `--bump` can now be repeated. The primary motivation of
this is "bump stable version and also enter a prerelease", but it
technically lets you express other things if you want them:

* `--bump patch --bump alpha` on `1.2.3` => `1.2.4a1` ("bump patch
version and go to alpha 1")
* `--bump minor --bump patch` on `1.2.3` => `1.3.1` ("bump minor version
and got to patch 1")
* `--bump minor --bump minor` on `1.2.3` => `1.4.0` ("bump minor version
twice")

The `--bump` flags are sorted by their priority, so that you don't need
to remember the priority yourself. This ordering is the only "useful"
one that preserves every `--bump` you passed, so there's no concern
about loss of expressiveness. For instance `--bump minor --bump major`
would just be `--bump major` if we didn't sort, as the major bump clears
the minor version. The ordering of `beta` after `alpha` means `--bump
alpha --bump beta` will just result in beta 1; this is the one case
where a bump request will effectively get overwritten.

The `stable` mode "bumps to the next stable release", clearing the pre
(`alpha`, `beta`, `rc`), `dev`, and `post` components from a version
(`1.2.3a4.post5.dev6` => `1.2.3`). The choice to clear `post` here is a
bit odd, in that `1.2.3.post4` => `1.2.3` is actually a version
decrease, but I think this gives a more intuitive model (as preserving
`post5` in the previous example is definitely wrong), and also
post-releases are extremely obscure so probably no one will notice. In
the cases where this behaviour isn't useful, you probably wanted to pass
`--bump patch` or something anyway which *should* definitely clear the
`post5` (putting it another way: the only cases where `--bump stable`
has dubious behaviour is when you wanted it to do a noop, which, is a
command you could have just not written at all).

In all cases we preserve the "epoch" and "local" components of a
version, so the `7!` and `+local` in `7!1.2.3+local` will never be
modified by `--bump` (you can use the raw version set mode if you want
to touch those). The preservation of `local` is another slightly odd
choice, but it's a really obscure feature (so again it mostly won't come
up) and when it's used it seems to mostly be used for referring to
variant releases, in which case preserving it tends to be correct.

Fixes #13223

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-10 08:45:17 -05:00
Zanie Blue 573b991398
Add nesting groups documentation for dependency groups (#14539) 2025-07-10 08:10:21 -05:00
Arthur Kim f900ef9e57
`setup-python/v5` exists, `v6` don't exists. (#14533)
## Summary

I suddenly found wrong documentation with setup-python in
https://docs.astral.sh/uv/guides/integration/github/#setting-up-python.

`setup-python/v5` exists, `setup-python/v6` don't exists.


## Test Plan

nothing
2025-07-10 06:17:30 -05:00
konsti e798b09aa4
Multiple modules in namespace packages (#14460)
Support multiple root modules in namespace packages by enumerating them:

```toml
[tool.uv.build-backend]
module-name = ["foo", "bar"]
```

This allows applications with multiple root packages without migrating
to workspaces. Since those are regular module names (we iterate over
them an process each one like a single module names), it allows
combining dotted (namespace) names and regular names. It also
technically allows combining regular and stub modules, even though this
is even less recommends.

We don't recommend this structure (please use a workspace instead, or
structure everything in one root module), but it reduces the number of
cases that need `namespace = true`.

Fixes #14435
Fixes #14438

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-09 17:45:44 +00:00
Zanie Blue 812a3e7c34
Bump version to 0.7.20 (#14525) 2025-07-09 12:15:41 -05:00
Charlie Marsh 4d061a6fc3
Add `--workspace` flag to `uv add` (#14496)
## Summary

You can now pass `--workspace` to `uv add` to add a path dependency as a
workspace member.

Closes https://github.com/astral-sh/uv/issues/14464.
2025-07-09 11:46:53 -04:00
Yu, Guangye b1dc2b71a3
Add auto-detection for Intel GPUs (#14386)
## Summary

This PR intends to enable `--torch-backend=auto` to detect Intel GPUs
automatically:
- On Linux, detection is performed using the `lspci` command via
`Display controller` id.
- On Windows, ~~detection is done via a `powershell` query to
`Win32_VideoController`~~. Skip support for now—revisit once a better
solution is available.

Currently, Intel GPUs (XPU) do not rely on specific driver or toolkit
versions to distribute different PyTorch wheels.

## Test Plan

<!-- How was it tested? -->
On Linux:

![image](https://github.com/user-attachments/assets/f7f238e3-a797-42ea-b8fa-9b028dfd4db5)
~~On Windows:

![image](https://github.com/user-attachments/assets/a10d774e-1cb9-431b-bb85-e3e8225df98f)~~

---------

Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
2025-07-09 13:31:08 +00:00
Charlie Marsh 5e2dc5a9aa
Remove `uv pip sync` suggestion with `pyproject.toml` (#14510)
## Summary

I think doing this would almost always be a mistake, since it won't
install any transitive dependencies. Instead, I took the opportunity to
mention the `pylock.toml` format.

Closes
https://github.com/astral-sh/uv/issues/14507#issuecomment-3050083116.
2025-07-08 16:13:02 -04:00
Zanie Blue dedced3265
Remove `cache-dependency-glob` examples for `setup-uv` (#14493)
See https://github.com/astral-sh/uv/pull/13163#discussion_r2063244551
2025-07-07 15:06:23 -05:00
theirix 5c6d76ca8b
Update documentation for GHA to use v6 (#14490)
## Summary

`astral-sh/setup-uv@v6` is the latest version of GitHub actions.

## Test Plan

Documentation update
2025-07-07 14:04:45 -05:00
Zanie Blue c3f13d2505
Finish incomplete sentence in pip migration guide (#14432)
Fixes https://github.com/astral-sh/uv/pull/12382#discussion_r2181237729
2025-07-03 01:02:17 +00:00
Zanie Blue 38ee6ec800
Bump version to 0.7.19 (#14431) 2025-07-02 21:19:52 +00:00
konsti 71b5ba13d7
Stabilize the uv build backend (#14311)
The uv build backend has gone through some feedback cycles, we expect no
more major configuration changes, and we're ready to take the next step:
The uv build backend in stable.

This PR stabilizes:

* Using `uv_build` as build backend
* The documentation of the uv build backend
* The direct build fast path, where uv doesn't use PEP 517 if you're
using `uv_build` in a compatible version.
* `uv build --list`, which is limited to `uv_build`.

It does not:
* Make `uv_build` the default on `uv init`
* Make `--package` the default on `uv init`
2025-07-02 15:37:43 -05:00
Zanie Blue 2f53ea5c5c
Add a migration guide from pip to uv projects (#12382)
[Rendered](https://github.com/astral-sh/uv/blob/zb/pip-wip/docs/guides/migration/pip-to-project.md)

---------

Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
Co-authored-by: Mathieu Kniewallner <mathieu.kniewallner@gmail.com>
Co-authored-by: Aria Desires <aria.desires@gmail.com>
2025-07-02 12:25:19 -05:00