chore(deps-dev): Update uv requirement from 0.7.20 to 0.8.0

[dependabot]

Updates the requirements on uv to permit the latest version.

Release notes

Sourced from uv's releases.

0.8.0

Release Notes

Since we released uv 0.7.0 in April, we've accumulated various changes that improve correctness and user experience, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.

This release also includes the stabilization of a couple uv python install features, which have been available under preview since late last year.

Breaking changes

• Install Python executables into a directory on the PATH (#14626)

  uv python install now installs a versioned Python executable (e.g., python3.13) into a directory on the PATH (e.g., ~/.local/bin) by default. This behavior has been available under the --preview flag since Oct 2024. This change should not be breaking unless it shadows a Python executable elsewhere on the PATH.

  To install unversioned executables, i.e., python3 and python, use the --default flag. The --default flag has also been in preview, but is not stabilized in this release.

  Note that these executables point to the base Python installation and only include the standard library. That means they will not include dependencies from your current project (use uv run python instead) and you cannot install packages into their environment (use uvx --with <package> python instead).

  As with tool installation, the target directory respects common variables like XDG_BIN_HOME and can be overridden with a UV_PYTHON_BIN_DIR variable.

  You can opt out of this behavior with uv python install --no-bin or UV_PYTHON_INSTALL_BIN=0.

  See the documentation on installing Python executables for more details.

• Register Python versions with the Windows Registry (#14625)

  uv python install now registers the installed Python version with the Windows Registry as specified by PEP 514. This allows using uv installed Python versions via the py launcher. This behavior has been available under the --preview flag since Jan 2025. This change should not be breaking, as using the uv Python versions with py requires explicit opt in.

  You can opt out of this behavior with uv python install --no-registry or UV_PYTHON_INSTALL_REGISTRY=0.

• Prompt before removing an existing directory in uv venv (#14309)

  Previously, uv venv would remove an existing virtual environment without confirmation. While this is consistent with the behavior of project commands (e.g., uv sync), it's surprising to users that are using imperative workflows (i.e., uv pip). Now, uv venv will prompt for confirmation before removing an existing virtual environment. If not in an interactive context, uv will still remove the virtual environment for backwards compatibility. However, this behavior is likely to change in a future release.

  The behavior for other commands (e.g., uv sync) is unchanged.

  You can opt out of this behavior by setting UV_VENV_CLEAR=1 or passing the --clear flag.

• Validate that discovered interpreters meet the Python preference (#7934)

  uv allows opting out of its managed Python versions with the --no-managed-python and python-preference options.

  Previously, uv would not enforce this option for Python interpreters discovered on the PATH. For example, if a symlink to a managed Python interpreter was created, uv would allow it to be used even if --no-managed-python was provided. Now, uv ignores Python interpreters that do not match the Python preference unless they are in an active virtual environment or are explicitly requested, e.g., with --python /path/to/python3.13.

  Similarly, uv would previously not invalidate existing project environments if they did not match the Python preference. Now, uv will invalidate and recreate project environments when the Python preference changes.

  You can opt out of this behavior by providing the explicit path to the Python interpreter providing --managed-python / --no-managed-python matching the interpreter you want.

• Install dependencies without build systems when they are path sources (#14413)

  When working on a project, uv uses the presence of a build system to determine if it should be built and installed into the environment. However, when a project is a dependency of another project, it can be surprising for the dependency to be missing from the environment.

... (truncated)

Changelog

Sourced from uv's changelog.

0.8.0

Since we released uv 0.7.0 in April, we've accumulated various changes that improve correctness and user experience, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.

This release also includes the stabilization of a couple uv python install features, which have been available under preview since late last year.

Breaking changes

• Install Python executables into a directory on the PATH (#14626)

  uv python install now installs a versioned Python executable (e.g., python3.13) into a directory on the PATH (e.g., ~/.local/bin) by default. This behavior has been available under the --preview flag since Oct 2024. This change should not be breaking unless it shadows a Python executable elsewhere on the PATH.

  To install unversioned executables, i.e., python3 and python, use the --default flag. The --default flag has also been in preview, but is not stabilized in this release.

  Note that these executables point to the base Python installation and only include the standard library. That means they will not include dependencies from your current project (use uv run python instead) and you cannot install packages into their environment (use uvx --with <package> python instead).

  As with tool installation, the target directory respects common variables like XDG_BIN_HOME and can be overridden with a UV_PYTHON_BIN_DIR variable.

  You can opt out of this behavior with uv python install --no-bin or UV_PYTHON_INSTALL_BIN=0.

  See the documentation on installing Python executables for more details.

• Register Python versions with the Windows Registry (#14625)

  uv python install now registers the installed Python version with the Windows Registry as specified by PEP 514. This allows using uv installed Python versions via the py launcher. This behavior has been available under the --preview flag since Jan 2025. This change should not be breaking, as using the uv Python versions with py requires explicit opt in.

  You can opt out of this behavior with uv python install --no-registry or UV_PYTHON_INSTALL_REGISTRY=0.

• Prompt before removing an existing directory in uv venv (#14309)

  Previously, uv venv would remove an existing virtual environment without confirmation. While this is consistent with the behavior of project commands (e.g., uv sync), it's surprising to users that are using imperative workflows (i.e., uv pip). Now, uv venv will prompt for confirmation before removing an existing virtual environment. If not in an interactive context, uv will still remove the virtual environment for backwards compatibility. However, this behavior is likely to change in a future release.

  The behavior for other commands (e.g., uv sync) is unchanged.

  You can opt out of this behavior by setting UV_VENV_CLEAR=1 or passing the --clear flag.

• Validate that discovered interpreters meet the Python preference (#7934)

  uv allows opting out of its managed Python versions with the --no-managed-python and python-preference options.

  Previously, uv would not enforce this option for Python interpreters discovered on the PATH. For example, if a symlink to a managed Python interpreter was created, uv would allow it to be used even if --no-managed-python was provided. Now, uv ignores Python interpreters that do not match the Python preference unless they are in an active virtual environment or are explicitly requested, e.g., with --python /path/to/python3.13.

  Similarly, uv would previously not invalidate existing project environments if they did not match the Python preference. Now, uv will invalidate and recreate project environments when the Python preference changes.

  You can opt out of this behavior by providing the explicit path to the Python interpreter providing --managed-python / --no-managed-python matching the interpreter you want.

• Install dependencies without build systems when they are path sources (#14413)

  When working on a project, uv uses the presence of a build system to determine if it should be built and installed into the environment. However, when a project is a dependency of another project, it can be surprising for the dependency to be missing from the environment.

... (truncated)

Commits

• 0b23572 Bump version to 0.8.0
• 1f88755 CHANGELOG: manylinux_2_28 is more like 2019 (#14696)
• 1a339b7 Add release notes and bump version for 0.8.0 (#14690)
• ac35377 Fix rendering of uv venv --clear hint in bash (#14691)
• 5b716c4 Add missing trailing newline to outdated error (#14689)
• cd40a34 Build and install workspace members that are dependencies by default (#14663)
• 0077f23 Stabilize addition of Python executables to the bin (#14626)
• ff30f14 Build path sources without build systems by default (#14413)
• b98ac8c Validate that discovered interpreters meet the Python preference (#7934)
• 2df06eb Require uv venv --clear before removing an existing directory (#14309)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)