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

Merged
merged 5 commits into from
Aug 8, 2025
Merged

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

@webknjaz webknjaz Jul 20, 2025

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

@cbrnr cbrnr Jul 20, 2025

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

@konstin konstin Jul 21, 2025

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

@webknjaz webknjaz Jul 30, 2025

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

@hroncok hroncok Jul 30, 2025

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
Member

@ncoghlan ncoghlan Aug 2, 2025

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?

Copy link
Member

@webknjaz webknjaz Aug 2, 2025

Choose a reason for hiding this comment

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

@ncoghlan I'm worried that accepting this as is would make the existing problem worse. And doing so is too impactful to just disregard it. The downstreams have expressed legitimate concern. Perhaps, we should address that issue you filed first so this PR wouldn't be as harmful?

@notatallshaw

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?

This is different because the example with setuptools is adding new features and when documenting them, the bound has to be updated for things to work. Inevitably.

But the same isn't happening when things break. Nobody comes in to update the guide documenting breakages and adjusting related bounds. And so there's no process for when this would be happening.

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?

Lower bounds are fine. Flit was mostly missed. It should also have an admonition explaining that upper bounds should be updated often. Maybe this admonition makes sense to have below all the examples, not selectively.

Copy link
Member

@ncoghlan ncoghlan Aug 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I guess my view is that the PR itself isn't really making things worse, it's instead making this existing problem with the status quo more obvious.

Omitting the upper bounds creates an "old project releases may not build" scenario that affects potentially everyone, whereas including them has a more limited impact specifically on "unified build environment" scenarios (which could potentially be mitigated by build tooling changes, such as an option to ignore upper bounds in build dependency declarations and see if anything actually breaks with the newer build tool versions).

Copy link
Member

@webknjaz webknjaz Aug 8, 2025

Choose a reason for hiding this comment

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

@mgorny @hroncok while merging this didn't exactly cater to your needs, I'd like to suggest discussing a systemic change to adding mentions of what's important for downstreams throughout PyPUG, if you're interested. Maybe, some admonitions linking to #1791 where relevant.

Copy link
Contributor

@konstin konstin Aug 26, 2025

Choose a reason for hiding this comment

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

I've filed a PR to automatically update the uv_build version range, to address the concern that the bounds would go stale: #1899

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