Release 0.8.0 #14164
Merged
Release 0.8.0 #14164
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
konstin
added
tracking
konstin
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
force-pushed
the
release/080
branch
3 times, most recently
from
a52c6d5 to
24f937c
Compare
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
cthoyt
reviewed
Jun 21, 2025
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
charliermarsh
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
charliermarsh
force-pushed
the
release/080
branch
from
e104eea to
de0b93c
Compare
charliermarsh
had a problem deploying
to
uv-test-registries
GitHub Actions
Error
charliermarsh
force-pushed
the
release/080
branch
from
de0b93c to
421e2c7
Compare
charliermarsh
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
charliermarsh
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
charliermarsh
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
charliermarsh
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
jtfmumm
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
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 pypa/cibuildwheel#1988, and there's a lot of discussion in pypa/cibuildwheel#1772 and pypa/cibuildwheel#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/):  Note that this only changes the _default_. Users can still compile against `manylinux_2_17` by specifying it.
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.
If a user specifies `-e /path/to/dir` and `/path/to/dir` in a `uv pip install` command, we want the editable to "win" (rather than erroring due to conflicting URLs). Unfortunately, this behavior meant that when you requested a package as editable and non-editable in conflicting groups, the editable version was _always_ used. This PR modifies the requisite types to use `Option<bool>` rather than `bool` for the `editable` field, so we can determine whether a requirement was explicitly requested as editable, explicitly requested as non-editable, or not specified (as in the case of `/path/to/dir` in a `requirements.txt` file). In the latter case, we allow editables to override the "unspecified" requirement. If a project includes a path dependency twice, once with `editable = true` and once without any `editable` annotation, those are now considered conflicting URLs, and lead to an error, so I've marked this change as breaking. Closes #14139.
We weren't following our usual "destructure all the options" pattern in this function, and several "this isn't actually read from uv.toml" fields slipped through the cracks over time since folks forgot it existed. Fixes part of #14308, although we could still try to make the warning in FilesystemOptions more accurate? You could argue this is a breaking change, but I think it ultimately isn't really, because we were already silently ignoring these fields. Now we properly error.
In the case of `uv sync` all we really need to do is handle the `OutdatedEnvironment` error (precisely the error we yield only on dry-runs when everything Works but we determine things are outdated) in `OperationDiagnostic::report` (the post-processor on all `operations::install` calls) because any diagnostic handled by that gets downgraded to from status 2 to status 1 (although I don't know if that's really intentional or a random other bug in our status handling... but I figured it's best to highlight that other potential status code incongruence than not rely on it 😄). Fixes #12603 --------- Co-authored-by: John Mumm <[email protected]>
Fixes #14157 --------- Co-authored-by: John Mumm <[email protected]>
…`) (#14661) Closes #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 = "[email protected]" } ] 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 = "[email protected]" } ] 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.
Following #14614 this is non-fatal and has an opt-out so it should be safe to stabilize.
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 <[email protected]>
Closes #5144 e.g. ``` ❯ cargo run -q -- sync --python-preference only-system Using CPython 3.12.6 interpreter at: /opt/homebrew/opt/[email protected]/bin/python3.12 Removed virtual environment at: .venv Creating virtual environment at: .venv Resolved 9 packages in 14ms Installed 8 packages in 9ms + anyio==4.6.0 + certifi==2024.8.30 + h11==0.14.0 + httpcore==1.0.5 + httpx==0.27.2 + idna==3.10 + ruff==0.6.7 + sniffio==1.3.1 ❯ cargo run -q -- sync --python-preference only-managed Using CPython 3.12.1 Removed virtual environment at: .venv Creating virtual environment at: .venv Resolved 9 packages in 14ms Installed 8 packages in 11ms + anyio==4.6.0 + certifi==2024.8.30 + h11==0.14.0 + httpcore==1.0.5 + httpx==0.27.2 + idna==3.10 + ruff==0.6.7 + sniffio==1.3.1 ```
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 <[email protected]>
…14663) Regardless of the presence of a build system, as in #14413 --------- Co-authored-by: John Mumm <[email protected]>
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
Unlike the other branch in match, which uses a fully formatted error, we need to print the newline ourselves. Before (top) and after (bottom): <img width="1296" height="585" alt="image" src="https://github.com/user-attachments/assets/b4122ed5-591b-4fd9-a9b7-31b1e506d8aa" />
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
zanieb
temporarily deployed
to
uv-test-registries
GitHub Actions
Inactive
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tracking branch for the 0.8.0 release