This ticket asks FESCo to consider whether the uv package should be granted a permanent exception under the Updates Policy.
uv
The uv package is a “Python package and project manager, written in Rust.” It reasonably claims to offer “a single tool to replace pip, pip-tools, pipx, poetry, pyenv, virtualenv, and more.” While uv is already seeing wide use in the Python community, it has only been publicly available for about six months, and it is still being developed very rapidly, typically releasing more than once a week.
pip
pip-tools
pipx
poetry
pyenv
virtualenv
We can expect that there will be one or more technically-incompatible minor-version bumps during the life of a Fedora release, similar to the just-announced 0.3.0 (release notes, blog post). There are a few small breaking changes documented in the release notes, but – particularly considering that uv is primarily used directly by developers rather than for building other distribution packages – the benefits of keeping this tool current seem to more than counterbalance these minor incompatibilities.
That is, for this particular package, holding the package at older version in stable releases would seem to do much more harm to Fedora users than exposing them to minor breaking changes. This is basically the same rationale as for other Python development tools that were already granted similar exceptions, like ruff, tox, and black (previously, previously).
ruff
tox
black
If this exception is granted, uv package maintainers may still choose to keep an old version in certain branches – for example, if the branch is near its end-of-life date, or if the breaking changes in a new version appear too disruptive – and the usual care should be taken to avoid impacting any Fedora packages that do end up depending on uv.
Seems reasonable. +1
Metadata Update from @ngompa: - Issue tagged with: updates policy exception
+1
I hesitate here; if this tool is so unstable that it's breaking API that frequently, maybe we should wait to even allow it in Fedora at all. I don't like the idea of a build tool that isn't reliable.
Ruff, tox and black at least were supplementary tools; linters and test runners. It sounds like uv is a low-level build tool that, if it breaks, will lead to a lot of mid-stream FTBFS situations.
Frankly, rather than grant a blanket updates exception, I wonder if we shouldn't be disallowing its use in Fedora entirely until its development stabilizes.
I'd also like to solicit @churchyard 's opinion here.
For now, I'm casting a procedural -1 vote so this will need to be discussed in a meeting.
Metadata Update from @sgallagh: - Issue tagged with: meeting
It should be noted that uv upstream seems to be documenting breaking changes very fastidiously. For the 0.3.0 release, they list:
--legacy-setup-py
They also note that the “uv pip interface should not be affected by any breaking changes.”
uv pip
Considering the number of features uv exposes, this is a pretty minuscule list.
While I think this is representative of upstream’s intent to avoid significant breaking changes and stay consistent with existing tools, I concede that there is no guarantee that future breaking changes will always be this minor.
I would like to clarify that uv is not a build tool, in that it does not offer a Python build backend like flit-core, poetry-core, pdm, or hatchling.
flit-core
poetry-core
pdm
hatchling
It is purely a command-line tool, and has no Python API; there is a trivial uv package that can imported from Python, but its only feature is finding the path to the uv command-line executable.
As described in https://astral.sh/blog/uv#a-drop-in-compatible-api, the uv pip command-line API encompassing most of the functionality in 0.2.x is intended to be the lowest-level part of uv; future functionality is expected to be even higher-level. The developers of uv see it as eventually being cargo for Python.
cargo
Since uv was introduced to Fedora about three weeks ago, there are a handful of packages that do depend on it.
fawltydeps
python-build
hatch
I can’t forecast how use of uv will evolve in the long term, but I think these are pretty characteristic of the kinds of uv dependencies we’ll see in the short and mid term.
If FESCo is uncomfortable with granting a permanent blanket exception, I’m also willing to submit individual exception requests for particular releases as required. If the permanent exception request is not approved, I plan to ask for an exception for uv 0.3.0 in F40 and F39, citing the small list of breaking changes and the fact that uv 0.2.x has been available in those stable releases for only two weeks.
My opinion is that we MUST have uv in Fedora to remain relevant; and we SHOULD strive for the latest version possible, not to produce an outdated version and bad developer experience. I support this permanent exception request. If the situation changes in the future, we can revoke it.
+1 too.
(I agree with what @churchyard wrote. For developer tools like this, having the latest version is important. Usually everybody in the ecosystem will be using and talking about this latest version. This is different than other more stable and widely known tools, where stability during a fedora release is much more relevant.)
It sounds like uv is a low-level build tool that, if it breaks, will lead to a lot of mid-stream FTBFS situations.
Yeah, I agree with @music: I wouldn't describe uv as a low-level build tool. uv is meant for Python users and developers in their local environments. It's not a build backend like setuptools that is a core build dependency for many other Python packages, and it's not bundled with Python or used with the RPM Python macros like pip, so future breaking changes shouldn't really break other packages or cause FTBFSs.
If uv starts being used internally by a ton of other packages or a breaking change is particularly groundbreaking, then yeah, we wouldn't want to update it in stable releases, but I think at least until the 1.0.0 release, a permanent Updates Policy exception is warranted. At least the main uv pip API is pretty set in stone, and shouldn't change much, I don't think.
My opinion is that we MUST have uv in Fedora to remain relevant; and we SHOULD strive for the latest version possible, not to produce an outdated version and bad developer experience. I support this permanent exception request. If the situation changes in the future, we can revoke it. ... If uv starts being used internally by a ton of other packages or a breaking change is particularly groundbreaking, then yeah, we wouldn't want to update it in stable releases, but I think at least until the 1.0.0 release, a permanent Updates Policy exception is warranted. At least the main uv pip API is pretty set in stone, and shouldn't change much, I don't think.
OK, I'm convinced, but I think I like @gotmax23's proposal of "until 1.0.0 release". Can we put that constraint on it, that the permanent exception expires when upstream declares the API stable? I'd be +1 for that.
But if the API is declared stable, then what's the point of forbidding upgrades?
If the API is declared stable, it means we don't need an exception for them to perform upgrades. And that we should re-evaluate if they then later need to have an API break (such as a 2.0.0 release).
I'm not saying we disallow upgrades at that point, just that the automatic exception for incompatible updates ends.
But if the API is declared stable, then what's the point of forbidding upgrades? If the API is declared stable, it means we don't need an exception for them to perform upgrades. And that we should re-evaluate if they then later need to have an API break (such as a 2.0.0 release). I'm not saying we disallow upgrades at that point, just that the automatic exception for incompatible updates ends.
Right, that's exactly my point.
I have no objection to this stipulation.
+1 to @gotmax23 's proposal
+1 to grant uv a more permanent exception, at least until 1.0 comes out, at which point it should not have breaking changes anymore anyway, as gotmax noted.
From the original proposal, it sounds like the uv maintainers will do due diligence before any upgrade to identify broken dependents anyway, so that's reassuring.
Metadata Update from @sgallagh: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @sgallagh: - Issue untagged with: meeting
This still needs to be documented before closing.
Metadata Update from @ngompa: - Issue status updated to: Open (was: Closed) - Issue tagged with: document it
https://pagure.io/fesco/fesco-docs/pull-request/92
Metadata Update from @music: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: document it
Log in to comment on this ticket.