Release Notes

Released on 2026-07-28.

Since we released uv 0.11.0 in March, we've accumulated changes that improve correctness, safety, and compatibility with specifications, 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.

There are no breaking changes to the configuration of the uv build backend. If your [build-system] table includes an upper bound on uv_build, update it to allow uv_build 0.12, e.g., uv_build>=0.11.32,<0.13.

Breaking changes

  • Define build systems by default with(#19197)uv initProjects created with uv initnow declare a build system and are packaged by default. This was the default project layout all the way back in v0.3, but we found that the use of thehatchlingbuild system was confusing to newcomers and consequently dropped use of a build system by default in v0.4. Since then, we've created our own build system (uv_build) with tight integration with uv and are excited to restore the default to a best-practice project layout.Previously, uv init examplecreated an unpackaged layout containingmain.pyand apyproject.tomlwithout a build system. The project could declare dependencies but was not itself installed into its virtual environment.Now, uv init exampledefines a[build-system]usinguv_build, places application source code insrc/example, and includes a[project.scripts]entry namedexample. Defining a build system allows the project to be imported from tests or other code, installed as a dependency, and run as a command:$ uv init example $ cd example $ uv run example Hello from example! Existing projects are unaffected. Use uv init --no-package exampleto create the previous unpackaged layout without a build system.See the project creation documentation for more details. This stabilizes the packaged-initpreview feature.
  • Reject unsupported source distribution and wheel archive formats(#18927)PEP 625 requires source distributions to use .tar.gzarchives. Previously, uv also accepted legacy formats such as.tar.bz2and.tar.xz. Those formats are now rejected, including when referenced by an existing lockfile. Legacy.zipsource distributions remain supported for backwards compatibility.Wheels and other ZIP archives can no longer contain entries compressed with bzip2, LZMA, or XZ. Entries must use the stored, DEFLATE, or zstd compression methods. Removing support for uncommon compression methods reduces uv's compression dependencies and the attack surface exposed when processing untrusted packages. You cannot opt out of this behavior. If you depend on a legacy source distribution that uses an unsupported format, we recommend rebuilding it as a .tar.gzarchive and regenerating any lockfile containing references to the legacy archive.
  • Reject wheel files that could replace the Python interpreter(#20748, #20749)uv already rejected wheel entry points named python, but case variants such asPythonwere still accepted. On case-insensitive filesystems, including common macOS and Windows setups, these entry points could overwrite the virtual environment's interpreter.Wheels could also place interpreter files in their .data/scriptsdirectory or in paths such as.data/data/bin/python, bypassing the entry-point check and replacing the interpreter during installation.uv now rejects case-insensitive variants of reserved interpreter names and wheel data files that would be installed over an interpreter. This includes names such as Python,python.py, andPython.exe, along with other reserved interpreter names and their versioned variants.You cannot opt out of these checks. Rename conflicting entry points or wheel data files and rebuild the affected wheel.
  • Prefer stable releases before falling back to pre-releases(#19993)A dependency can introduce a pre-release requirement after resolution starts. uv previously required each package's pre-release eligibility to be known before resolution began: the default if-necessary-or-explicitmode allowed them for direct requirements that explicitly requested a pre-release, or for packages that only published pre-releases.This meant that a pre-release requirement discovered in a dependency's metadata, e.g., example>=2.0.0b1, would fail to resolve even when a compatible pre-release existed. To resolve it, you had to add that dependency as a direct requirement or allow pre-releases across your entire dependency graph.The default mode is now if-necessary. uv tries stable candidates first and falls back to pre-releases when no stable candidate satisfies the active constraints. Like pip, uv now supports pre-release requirements discovered transitively, but can select different versions than previous uv releases when both stable and pre-release candidates are available.You can opt out of automatic pre-release selection with --prerelease disallow. Alternatively,--prerelease allowconsiders pre-releases without first preferring stable releases, and--prerelease explicitonly allows them for direct requirements that mention a pre-release.The old if-necessary-or-explicitmode distinguished between explicitly requested pre-releases and packages with no stable releases. That distinction is unnecessary now thatif-necessaryhandles both cases, including transitive requirements. The old name remains available as an alias but is deprecated and will be removed in a future release.
  • Respect(#19336)--require-hashesdirectives inrequirements.txtPreviously, uv pip installanduv pip syncwarned about--require-hashesinside arequirements.txtfile but still installed dependencies without checking their hashes. Now, the directive enables hash-checking mode, just as if--require-hasheshad been passed on the command line.For example, this requirements file is no longer accepted because the requirement is neither pinned nor hashed: --require-hashes anyioYou cannot opt out while the directive is present. Pin every requirement with ==and provide its hash, or remove--require-hashesif hash checking is not intended.
  • Reject MD5-only hashes in hash-checking mode(#20758)Previously, uv pip install --require-hashesanduv pip sync --require-hashesaccepted requirements whose only available digest used MD5. MD5 is not collision-resistant, so relying on it undermined installations that require hash verification and differed from pip's behavior.Hash-checking mode now requires at least one secure digest for every requirement. For example, the following requirement is rejected unless a secure hash, such as SHA-256, is also supplied: anyio==4.0.0 --hash=md5:420d85e19168705cdf0223621b18831aA secure hash can be supplied directly on the requirement or in a matching constraints file. Ordinary hash verification without --require-hashescontinues to support MD5.You cannot opt out while hash checking is required. Regenerate affected hashes with SHA-256 or another supported secure hash.
  • Reject invalid(#20402, #20440, #20443)pylock.tomlfiles and artifactsuv now validates additional requirements from the pylock.tomlspecification:- The packagesarray must be present. Previously, uv interpreted a missing array as an empty lockfile, souv pip synccould uninstall an environment instead of rejecting malformed input. An explicitly emptypackages = []array remains valid.
  • Lockfile filenames must be pylock.tomlor a single-name variant such aspylock.dev.toml. Names such aspylock..tomlandpylock.foo.bar.tomlare rejected.
  • If a wheel, source distribution, or other artifact declares a size, the downloaded or cached artifact must match. Previously, an incorrect size was accepted when the hash was correct. Sizes reported by package indexes remain advisory.
    You cannot opt out of these checks. Regenerate malformed lockfiles, rename invalid filenames, and either correct or remove an incorrect optional sizevalue.
  • The
  • Honor explicit certificate overrides even when no certificates can be loaded(#20741, #20767)Previously, uv ignored SSL_CERT_FILEorSSL_CERT_DIRvalues that pointed to missing or inaccessible paths, empty files or directories, or sources without valid certificates. Instead, it fell back to its default trust roots, potentially allowing HTTPS connections that the configured override was intended to reject.Now, any non-empty SSL_CERT_FILEorSSL_CERT_DIRvalue replaces uv's default certificate roots, even when no valid certificates can be loaded. In that case, HTTPS requests fail because no certificates are trusted. This applies to package downloads and remote scripts, including GitHub Gists.Fix or unset the certificate override. Unsetting it restores the default trust store; empty environment-variable values continue to be ignored.
  • Support pip-compatible(#20418)--certhandling inuv pipThe uv pipinterface now accepts--cert <path>, e.g.:$ uv pip install --cert ./company-ca.pem exampleAs in pip, the provided PEM bundle replaces all other certificate sources for that invocation, including system certificates and SSL_CERT_FILEorSSL_CERT_DIR. This change has no effect unless you pass--cert. Include the necessary certificate authorities in the bundle.--certis only supported byuv pipcommands; other uv commands continue to use their existing certificate configuration.
  • Discover projects relative to the script passed to(#20225)uv runPreviously, uv run project/script.pydiscovered its project from the current directory, even when the script belonged to another project. uv now starts project and workspace discovery from the script's directory instead.For example, running uv run other-project/script.pynow usesother-projectand its dependencies. This fixes scripts that previously failed because their own dependencies were not installed, but can select a different environment than before.You can opt out of script-relative discovery by selecting a project explicitly, e.g., uv run --project . other-project/script.py.This stabilizes the target-workspace-discoverypreview feature.
  • Require(#20225)--forcebefore clearing a directory that is not a virtual environmentuv venv --clearpreviously removed any existing target directory, even if it was not a virtual environment. uv emitted a warning but still deleted the directory and its contents. Now, uv refuses to clear directories that do not contain a virtual environment.You can opt out of this safety check by explicitly passing --force, e.g.,uv venv --clear --force ./not-a-virtualenv.This stabilizes the venv-safe-clearpreview feature.
  • Reject(#20225)--projectwhen initializing a project--projectselects an existing project, so it is not meaningful when initializing a new one. Previously,uv init --project examplewarned and initializedexampleanyway; if a positional path was also provided,--projectwas ignored.This usage is now an error. Use uv init exampleto initialize a project at the requested path, oruv init --directory exampleto change the working directory first.This stabilizes the init-project-flagpreview feature.
  • Reject missing or invalid(#20225)--projectpathsuv previously warned when --projectreferred to a missing directory or a file other thanpyproject.toml, but then attempted to continue. This could produce confusing errors later or run against an unintended project.Now, uv run --project missing pythonfails immediately instead of continuing. You cannot opt out of this behavior. Create the directory first or select an existing project. Passing--project path/to/pyproject.tomlremains supported and selects the file's parent directory.This stabilizes the project-directory-must-existpreview feature.
  • Skip distributions with non-normalized filenames when publishing(#20225)Distribution filenames must use normalized package names and versions. For example, a wheel for version 1.01.0should be namedexample-1.1.0-py3-none-any.whl, notexample-1.01.0-py3-none-any.whl.Previously, uv publishwarned about non-normalized filenames but still attempted to upload them. It now skips the affected wheels and source distributions instead.You cannot opt out of this behavior. Rebuild distributions with normalized filenames before publishing. This stabilizes the publish-require-normalizedpreview feature.
  • Classify Conda environments named(#20225)baseandrootby their pathsConda environments named baseorrootwere previously assumed to be the base Conda environment, even when they were ordinary child environments. uv now recognizes child Conda environments namedbaseorrootbased on their paths, as it already does for other names.You can opt out of automatic interpreter selection by requesting an interpreter explicitly with --python /path/to/python.This stabilizes the special-conda-env-namespreview feature.
  • Reject broken(#20433).venvsymlinks during environment discoveryPreviously, uv could ignore a broken .venvsymlink and continue searching parent directories for another virtual environment. As a result, commands such asuv pip installcould unexpectedly modify an unrelated ancestor environment.uv now stops at a broken .venvsymlink and reports its exact path. Errors encountered while reading virtual environment metadata, including permission failures, are also reported immediately instead of being ignored.You cannot opt out of this behavior. Repair or remove the broken .venvsymlink and correct any permissions that prevent uv from inspecting the environment.
  • Reinstall matching installed Python patch versions instead of upgrading implicitly(#20659)Before Python upgrades were supported, uv python install 3.12 --reinstalldoubled as a way to install the latest Python 3.12 patch release. Now that--upgradeis available,--reinstallreinstalls the matching patch releases that are already present.For example, if Python 3.12.6 and 3.12.7 are installed, uv python install 3.12 --reinstallreinstalls both versions instead of installing the latest available 3.12 release.You can recover the previous upgrade behavior with uv python install 3.12 --upgrade. Combine--upgrade --reinstallto reinstall only the latest patch.
  • Require(#18957)--upgrade-groupto name an existing dependency groupPreviously, uv lock --upgrade-group docssilently succeeded even if nodocsdependency group existed. uv now validates the requested group against the project, its workspace members, and workspace-level dependency groups.You cannot opt out of this behavior. Correct the group name or add it to [dependency-groups]. Legacytool.uv.dev-dependenciesstill satisfies--upgrade-group dev.
  • Resolve relative indexes and find-links against(#20740)--directoryThe --directoryoption changes the directory in which uv operates. Previously, relative index and find-links paths supplied on the command line were still resolved against the original working directory.uv now resolves --index,--default-index,--index-url,--extra-index-url, and--find-linksrelative to the directory selected by--directory. For example:$ uv add --directory project --index ./packages exampleThis now uses project/packagesinstead of./packagesin the original working directory. Absolute paths and indexes loaded from configuration files are unaffected.To preserve the previous target, pass an absolute path or adjust the relative path, e.g., --index ../packages.
  • Preserve absolute paths provided to(#18402)uv add``uv addpreviously converted every local dependency into a project-relative path, even when the original request used an absolute path or a literalfile://URL. It now preserves the form of the request inpyproject.tomlanduv.lock:$ uv add ../library # remains relative $ uv add /projects/library # remains absolute Absolute paths make a project less portable. Use a relative path to avoid recording an absolute path. URLs containing expanded variables retain their existing relative-path behavior.
  • Remove older PyPy distributions that are only available as bzip2 archives(#20423)Older PyPy patch releases that are only distributed as .tar.bz2archives are no longer available throughuv python install. These releases require unsupported bzip2 archives.The latest PyPy release for each supported Python minor version is available as a gzip-compressed archive and remains supported. For example, uv python list 3.10 --all-versionsstill includes the latest PyPy 3.10 release, but older bzip2-only patch releases are omitted.You cannot opt out of this behavior. Request a newer PyPy patch release instead.
  • Omit excluded-package comments when annotations are disabled(#20085)uv pip compile --no-annotatesuppresses comments describing the generated requirements file. Previously, a footer listing packages excluded with--unsafe-packagewas still included, even though annotations were disabled. That footer is now omitted.You can recover the footer by removing --no-annotate.

Stabilizations

  • TOML 1.0-compatible source distributions(#20225)uv_buildnow writes a TOML 1.0-compatiblepyproject.tomlwhen building source distributions, allowing older Python build frontends to consume projects that use newer TOML syntax. The original project file remains available in the archive aspyproject.toml.orig.This stabilizes the toml-backwards-compatibilitypreview feature.
  • Automatic open-file limit adjustment on Unix(#20225)On Linux and macOS, uv now attempts to raise the soft open-file limit at startup toward the hard limit, capped at 1,048,576 descriptors. The new limit also applies to subprocesses and reduces failures caused by running out of file descriptors. If the limit cannot be raised, uv continues running with the existing limit. This stabilizes the adjust-ulimitpreview feature.

Preview features

  • Allow uv upgradeto target multiple packages, upgrade all production dependencies, and exclude selected dependencies (#20338)

Bug fixes

  • Include extras activated by dependency groups when evaluating conflicts (#20237)

Install uv 0.12.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://releases.astral.sh/github/uv/releases/download/0.12.0/uv-installer.sh | sh### Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://releases.astral.sh/github/uv/releases/download/0.12.0/uv-installer.ps1 | iex"## Download uv 0.12.0

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo astral-sh/uvYou can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>