Skip to content

Add uv-build to table #1880

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
+12 −0
Open

Add uv-build to table #1880

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
9a6a435
Add uv-build to table
cbrnr Jul 16, 2025
bfd629b
Add uv in other places
cbrnr Jul 18, 2025
4bd6330
[pre-commit.ci] auto fixes from pre-commit.com hooks
pre-commit-ci[bot] Jul 18, 2025
f57c5bf
Use first version that supported PEP 639
cbrnr Jul 18, 2025
2f4a15a
Merge branch 'main' into patch-2
ncoghlan Aug 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions source/guides/writing-pyproject-toml.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -314,11 +314,13 @@ backend>` now support the new format as shown in the following table.
- flit-core [#flit-core-pep639]_
- pdm-backend
- poetry-core
- uv-build
* - 1.27.0
- 77.0.3
- 3.12
- 2.4.0
- `not yet <poetry-pep639-issue_>`_
- 0.7.19


.. _license:
Expand Down
8 changes: 8 additions & 0 deletions source/shared/build-backend-tabs.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,3 +32,11 @@
[build-system]
requires = ["pdm-backend >= 2.4.0"]
build-backend = "pdm.backend"
.. tab:: uv-build

.. code-block:: toml
[build-system]
requires = ["uv_build >= 0.7.19, <0.9.0"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upper limits are normally discouraged. What's the justification here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the note in their official docs: https://docs.astral.sh/uv/concepts/build-backend/#using-the-uv-build-backend

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We make (careful) breaking changes in the configuration format in 0.x releases, i.e. the configuration is only stable between >=0.x and <0.(x+1). Being a build backend, the usual concerns about upper bounds don't apply: The uv build backend is a binary with only a minimal Python shim, so older versions of the build backend will still work with newer Python versions. It has zero dependencies and is the only package in the build venv, so the aren't any conflicts the upper bound could cause.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being a build backend, the usual concerns about upper bounds don't apply

That may be true upstream, but may present a challenge for the downstream maintainers as they often have a single version of a thing across their entire repositories (per distro release).

cc @befeleme @hroncok @mgorny any downstream insights on this?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't encourage upper bounds here. If you do, we'll and up in a position where we cannot update uv-build until we lift them. We won't be even able to test the packages with the new uv-build version in Fedora because of the pin.

Thanks @webknjaz for the mention.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(That's a bit snarky... but I genuinely do believe it'll go stale unless the uv team has a stake in maintaining it)

Copy link
Contributor

@sinoroc sinoroc Aug 1, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think it is snarky at all. Generally, not just for build dependencies, I do not think having real version constraints in this guide makes sense, because indeed they can not be kept up to date. There should be a very obvious note leading to an explanation of why one should set version constraints with examples of how to write such version constraints and an advice to go check each project's own documentation regarding their versioning policies.

Copy link
Member

@notatallshaw notatallshaw Aug 1, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

, I do not think having real version constraints in this guide makes sense

When the advise from those projects is to add constraints the packaging guide should not provide conflicting advise. Creating two conflicting streams of advise is going to create user confusion.

because indeed they can not be kept up to date

I see regular PRs to update the setuptools lower bound, why would this be any different?

There should be a very obvious note leading to an explanation of why one should set version constraints with examples of how to write such version constraints and an advice to go check each project's own documentation regarding their versioning policies.

Every other build back end has lower bound version constraints, flit has lower and upper: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/

Why are you adding this requirement for uv_build when it's not been required to any other build back end?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should refrain from posting when I do not have the time to post clear messages...

By "real version constraints", I mean version constraints with actual numbers. I wonder if instead of writing uv_build >= 0.7.19, <0.9.0 we could write uv_build >= M.m.b, < M+1.0.0 and then explain what that means, why it might be useful, and recommend users to refer to the project's documentation for more details to figure out what are the best current actual numbers. And of course, we would do that for all build back-ends (not just for Uv) and wherever else in the guide we might have such things.

But if people are willing to update those version strings in the guide all the time, it is fine by me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting back to the specific question of this PR review (rather than the more general ones of showing exact version numbers and upper bounds in build dependencies):

  • mentioning uv-build is a reasonable change to make
  • the exact build backend version number problem is an existing issue, not new in this PR
  • the upper bound problem is an existing issue (due to flit), not new in this PR

That says to me that we should define a new PyPUG issue regarding the maintainability of those config snippets, and avoid having that concern block this PR.

I've created that issue here: #1886

@webknjaz Given the creation of the dedicated issue, are you happy to consider the question resolved for the purpose of adding uv-build to the example backends?

build-backend = "uv_build"
2 changes: 2 additions & 0 deletions source/tutorials/managing-dependencies.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -177,3 +177,5 @@ and techniques, listed in alphabetical order, to see if one of them is a better
structured as a distributable Python package with a valid ``pyproject.toml`` file.
By contrast, Pipenv explicitly avoids making the assumption that the application
being worked on will support distribution as a ``pip``-installable Python package.
* `uv <https://docs.astral.sh/uv/>`__ for a single tool that covers the entire project
management workflow, including dependency management, packaging, and publishing.
Loading