Add release notes and bump version for 0.8.0 by zanieb · Pull Request #14690 · astral-sh/uv

zanieb · 2025-07-17T20:25:01Z

Rendered

CHANGELOG.md

ntBre

Nice! I only saw two tiny nits and a question on the 0.7 notes.

CHANGELOG.md

geofft · 2025-07-17T20:48:35Z

CHANGELOG.md

+Since we released [0.7.0](https://github.com/astral-sh/uv/releases/tag/0.5.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.


It's true that even users who are "broken" have a path forward, they just might have to tweak things, right? Do you want to say that explicitly somehow?

Possibly

Suggested change

Since we released [0.7.0](https://github.com/astral-sh/uv/releases/tag/0.5.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.

Since we released [0.7.0](https://github.com/astral-sh/uv/releases/tag/0.5.0) in April, we've

accumulated various changes that improve correctness and user experience, but could be backwards-incompatible for some

workflows. This release contains those changes; many have been marked as backwards-incompatible out of an

abundance of caution. We expect most users to be able to upgrade without making changes.

I'm not sure I want to change this — the language is copied from our previous releases and I don't think it's much clearer as you've proposed.

CHANGELOG.md

geofft · 2025-07-17T21:06:25Z

CHANGELOG.md

+  are built and installed, regardless of the presence of a build system. If a build system is not
+  present, the `setuptools.build_meta:__legacy__ ` backend will be used (per the standards).
+
+  You can opt-out of this behavior by setting `package = false` in the source declaration.


Is there a reason that one would want to opt out of this? Like I understand that this is breaking in the sense that import foo might succeed when it previously failed, but is there some common(-ish) case where people might run into this, like tests, or placeholders for foreign-language code, or something, that would be worth alluding to here?

Your package might not build.

CHANGELOG.md

geofft · 2025-07-17T21:18:49Z

CHANGELOG.md

+  dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/#virtual-dependencies) for
+  details.
+
+- **Bump `--python-platform linux` to `manylinux_2_28` ([#14300](https://github.com/astral-sh/uv/pull/14300))**


A suggestion for alternative text / framing that you may or may not want to try to incorporate:

Several popular Python packages are written partly or even mostly in a compiled language (like C, C++, or Rust) instead of in Python for performance and functionality. These packages can made available on PyPI as both source code as well as precompiled binaries ("wheels") for common platforms.

A precompiled wheel needs to be compatible with the OS you're running for it to work. The manylinux_2_17 tag, our old default, is compatible with most Linux distributions from 2014 or newer. At this point this is a little too widely compatible and prevents using newer Linux features. We now default to manylinux_2_24, which is compatible with most Linux distributions from 2017 or newer. This change follows the lead of other tools such as cibuildwheel...

OK now that I understand the change a little bit better:

Several popular Python packages are written partly or even mostly in a compiled language (like C, C++, or Rust) instead of in Python for performance and functionality. These packages can made available on PyPI as both source code as well as precompiled binaries ("wheels") for common platforms. Precompiled wheels are significantly faster and more reliable to install than building code from source.

A precompiled wheel needs to be compatible with the OS you're running for it to work. When uv installs packages for your system, it detects the version of your OS to find a compatible precompiled wheel if one is available. However, if you are using the --python-platform linux option for uv pip compile, uv pip install, and a few other subcommands, we previously defaulted to manylinux_2_17, compatible with most Linux distributions from 2014 or newer. At this point this is a little too widely compatible and prevents using newer Linux features, and third-party projects are looking to target a newer baseline. --python-platform linux now defaults to manylinux_2_24, compatible with most Linux distributions from 2017 or newer. This change follows the lead of other tools in the ecosystem like cibuildwheel, and ensures that resolutions from --python-platform linux are likely to find precompiled wheels if they exist while still maximizing compatibility.

Most users of uv will never need to specify --python-platform, but it may affect you if you are using uv to generate environments or requirements.txt files to run on other systems. If you know the exact OS version of the Linux systems you are targeting, it might be a good idea to specify the highest compatible manylinux version for those systems to get the best available packages, instead of using --python-platform linux.

You can opt out of this behavior by replacing --python-platform linux with --python-platform x86_64-manylinux_2_17.

While this is nice, I think this description is really not proportionate to the size of the change 😬 I'm pretty hesitant to say this much?

Lemme try to rework this to make it terser, I do think we need to clarify what this doesn't effect.

I did add that though?

uv pip compile, uv pip install, and a few other subcommands have a --python-platform option that lets you perform a platform-specific resolution for a platform other than your current one.

--python-platform linux is shorthand for a particular manylinux tag that is widely compatible. Previously, it was shorthand for manylinux_2_17, compatible with most Linux distributions from approximately 2014 onward. Now, it is shorthand for manylinux_2_28, compatible with most Linux distributions from approximately 2017 onward.

As third-party packages drop support for building precompiled wheels on very old Linux distributions, this improves the likelihood that uv will successfully find precompiled wheels when resolving packages. In particular, as of March 2025, cibuildwheel now defaults to manylinux_2_28.

This change does not affect uv's resolution behavior if you do not specify --python-platform; it will continue to detect your current OS version.

You can opt out of this behavior by replacing --python-platform linux with --python-platform x86_64-manylinux_2_17.

geofft · 2025-07-17T21:20:20Z

CHANGELOG.md

+  As described above for dependencies with `path` sources, uv previously would not build and install
+  workspace members that did not declare a build system. Now, uv will build and install workspace


and should reduce cases where uv needs to build a wheel from source.

I don't think this is right, is it? When installing a package / consuming a wheel, we detect manylinux compatibility based on the current glibc (I hope???). ~~And strictly speaking this change will increase the number of cases where people need to build from source, but that's a good tradeoff.~~ (no that's not true)

I'm quoting from Charlie's pull request. If you request a specific manylinux target, then we won't detect compatibility from your glibc.

I'll just drop that comment.

Oh I think I understand the thing that is wacky to me - if you are on e.g. glibc 2.40, and you do uv pip install --python-platform linux, and the only wheel available is manylinux_2_30, then we will not use that wheel and we'll build from source, but the resulting locally-compiled wheel will be built against glibc 2.40.

The thing I had in mind is that, in the uv pip compile case, we aren't building any wheels, and any consumer of the resulting requirements.txt file (either uv or pip) is likely to autodetect glibc compatibility and pick up wheels. ... ... except that we are building wheels because we can't detect deps out of an sdist, right? but we're going to be building a local wheel against the local glibc and reading deps out of it, ugh

charliermarsh · 2025-07-17T21:24:19Z

CHANGELOG.md

+  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.


So uv sync will still automatically tear down and re-create?

Yeah definitely.

charliermarsh · 2025-07-17T21:24:42Z

CHANGELOG.md

+
+  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.


"opt out of this behavior" => something about how "opting out" means continuing to remove environments without confirmation.

Hm I started with that pattern for the "opt out" statements but removed it because it was redundant. I kind of want the language to match across items.

Maybe "To match the behavior from 0.7.x., ..." for all of them?

geofft · 2025-07-17T21:24:42Z

CHANGELOG.md

+  You cannot opt out of this behavior. Use consistent `editable` settings or [mark groups as
+  conflicting](https://docs.astral.sh/uv/concepts/projects/config/#conflicting-dependencies).
+
+- **Make `uv_build` the default build backend in `uv init` ([#14661](https://github.com/astral-sh/uv/pull/14661))**


Brief note about why we're doing this? Performance?

I think that's covered in the stabilization post, I guess I can elevate that more? A uv build backend being the default for uv makes sense to people in a way that hatchling does not.

CHANGELOG.md

charliermarsh · 2025-07-17T21:27:05Z

CHANGELOG.md

+
+- **Require `--global` for removal of the global Python pin ([#14169](https://github.com/astral-sh/uv/pull/14169))**
+
+  Previously, `uv python pin --rm` would allow you to remove the global Python pin without opt in.


without opt-in, maybe?

That's my preference too but I guess it's wrong? #14690 (comment)

I'd probably say "without opting in" here, to sidestep the issue a bit

charliermarsh · 2025-07-17T21:27:53Z

CHANGELOG.md

+  not install tools into a directory on the `PATH` without additional configuration. Now, `UV_TOOL_BIN_DIR` is set to
+  `/usr/local/bin` in all Docker derived images.
+
+  When the default image user is overwritten (e.g. `USER <UID>`) by a less privileged one, this may


Maybe "by a less privileged image"

(less privileged user, not image)

It's the user that's less privileged.

konstin · 2025-07-17T21:17:46Z

CHANGELOG.md

+
+### Breaking changes
+
+- **Install Python executables into the bin ([#14626](https://github.com/astral-sh/uv/pull/14626))**


"into PATH" maybe? bin is an overloaded word by itself

konstin · 2025-07-17T21:22:11Z

CHANGELOG.md

+
+  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


VS Code also uses that to discover interpreters (https://learn.microsoft.com/en-us/visualstudio/python/managing-python-environments-in-visual-studio?view=vs-2022). I don't fully understand how else VS Code finds interpreters, so I don't know how much impact that has for VS Code users.

konstin · 2025-07-17T21:28:33Z

CHANGELOG.md

+
+  Or, by setting `tool.uv.package = false` in the dependent `pyproject.toml`.
+
+  See the documentation on [virtual


To avoid alarming users about checking what their glibc version is, I'd add a sentence that this only affects user of that specific option (which is rare), we use the host glibc version for all other use cases such as uv pip install and uv sync.

Yes, that's my concern - it took me a while to understand that this does not affect normal resolution or normal builds (since uv doesn't do builds in manylinux containers, that's cibuildwheel's job).

konstin · 2025-07-17T21:34:57Z

crates/uv-build-backend/src/lib.rs

        assert_snapshot!(
            format!("{:x}", sha2::Sha256::digest(fs_err::read(&source_dist_path).unwrap())),
-            @"dab46bcc4d66960a11cfdc19604512a8e1a3241a67536f7e962166760e9c575c"
+            @"9a7f7181c5e69ac14e411a2500fed153a1e6ea41cd5da6f24f226c4cddacf6b7"


We should start mocking the uv version in this test to prevent this hash from changing.

CHANGELOG.md

geofft · 2025-07-17T22:02:00Z

CHANGELOG.md

+
+  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.


Maybe "To match the behavior from 0.7.x., ..." for all of them?

geofft · 2025-07-17T22:02:31Z

CHANGELOG.md

+  dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/#virtual-dependencies) for
+  details.
+
+- **Bump `--python-platform linux` to `manylinux_2_28` ([#14300](https://github.com/astral-sh/uv/pull/14300))**


Lemme try to rework this to make it terser, I do think we need to clarify what this doesn't effect.

zanieb commented Jul 17, 2025

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

zanieb commented Jul 17, 2025

View reviewed changes

CHANGELOG.md Show resolved Hide resolved

Add release notes for 0.8.0

132885c

zanieb force-pushed the zb/release-notes branch from bf7e2d3 to 132885c Compare July 17, 2025 20:26

zanieb temporarily deployed to uv-test-registries July 17, 2025 20:29 — with GitHub Actions Inactive

zanieb added no-build Disable building binaries in CI test:skip Disable running tests for a pull request and removed test:skip Disable running tests for a pull request labels Jul 17, 2025

Update uv_build requirement in test package

7dd47f2

zanieb force-pushed the zb/release-notes branch from 51d6720 to 7dd47f2 Compare July 17, 2025 20:35

Add frontmatter

6e95b2f

zanieb changed the title ~~Add release notes for 0.8.0~~ Add release notes and bump verison for 0.8.0 Jul 17, 2025

zanieb temporarily deployed to uv-test-registries July 17, 2025 20:41 — with GitHub Actions Inactive

zanieb changed the title ~~Add release notes and bump verison for 0.8.0~~ Add release notes and bump version for 0.8.0 Jul 17, 2025

Update dist snapshot

c2eb80f

zanieb temporarily deployed to uv-test-registries July 17, 2025 20:48 — with GitHub Actions Inactive

Review

d06a630

ntBre reviewed Jul 17, 2025

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

CHANGELOG.md Outdated Show resolved Hide resolved

CHANGELOG.md Outdated Show resolved Hide resolved

geofft reviewed Jul 17, 2025

View reviewed changes

zanieb temporarily deployed to uv-test-registries July 17, 2025 21:21 — with GitHub Actions Inactive

charliermarsh reviewed Jul 17, 2025

View reviewed changes

Review

095183d

zanieb force-pushed the zb/release-notes branch from 5eaf4e9 to 095183d Compare July 17, 2025 21:26

geofft reviewed Jul 17, 2025

View reviewed changes

charliermarsh approved these changes Jul 17, 2025

View reviewed changes

zanieb temporarily deployed to uv-test-registries July 17, 2025 21:29 — with GitHub Actions Inactive

konstin approved these changes Jul 17, 2025

View reviewed changes

More review

5c59786

zanieb temporarily deployed to uv-test-registries July 17, 2025 21:58 — with GitHub Actions Inactive

zanieb added the test:skip Disable running tests for a pull request label Jul 17, 2025

zanieb force-pushed the zb/release-notes branch from 4f4b256 to 3e77dcd Compare July 17, 2025 22:01

geofft reviewed Jul 17, 2025

View reviewed changes

Reflow

bf45504

zanieb force-pushed the zb/release-notes branch from 3e77dcd to bf45504 Compare July 17, 2025 22:04

zanieb mentioned this pull request Jul 17, 2025

Mock the uv version in the uv_build test to avoid hash changes #14695

Closed

zanieb merged commit 5d097d4 into release/080 Jul 17, 2025
95 checks passed

zanieb deleted the zb/release-notes branch July 17, 2025 22:07

zanieb mentioned this pull request Jul 17, 2025

Bump version to 0.8.0 #14697

Merged

		As described above for dependencies with `path` sources, uv previously would not build and install
		workspace members that did not declare a build system. Now, uv will build and install workspace


		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.


		- Require `--global` for removal of the global Python pin ([#14169](https://github.com/astral-sh/uv/pull/14169))

		Previously, `uv python pin --rm` would allow you to remove the global Python pin without opt in.


		### Breaking changes

		- Install Python executables into the bin ([#14626](https://github.com/astral-sh/uv/pull/14626))


		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


		Or, by setting `tool.uv.package = false` in the dependent `pyproject.toml`.

		See the documentation on [virtual

Conversation

zanieb commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ntBre left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

geofft Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

zanieb commented Jul 17, 2025 •

edited

Loading

geofft Jul 17, 2025 •

edited

Loading