Permanent Updates Policy exception for uv

music commented

2024-08-21 19:06:15 +00:00

This ticket asks FESCo to consider whether the uv package should be granted a permanent exception under the Updates Policy.

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.

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

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.

This ticket asks FESCo to consider whether the `uv` package should be granted a [permanent exception under the Updates Policy](https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions). The [`uv`](https://src.fedoraproject.org/rpms/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. 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](https://github.com/astral-sh/uv/releases/tag/0.3.0), [blog post](https://astral.sh/blog/uv-unified-python-packaging)). 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`](https://pagure.io/fesco/issue/3197), [`tox`, and `black`](https://pagure.io/fesco/issue/2652) ([previously](https://pagure.io/fesco/issue/2525), [previously](https://pagure.io/fesco/issue/2259)). 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`.

ngompa commented

2024-08-21 19:06:56 +00:00

Owner

Seems reasonable. +1

ngompa commented

2024-08-21 19:06:56 +00:00

Owner

Metadata Update from @ngompa:

Issue tagged with: updates policy exception

**Metadata Update from @ngompa**: - Issue tagged with: updates policy exception

decathorpe commented

2024-08-21 19:10:48 +00:00

Owner

+1

sgallagh commented

2024-08-21 19:38:47 +00:00

Owner

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.

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.

sgallagh commented

2024-08-21 19:38:48 +00:00

Owner

Metadata Update from @sgallagh:

Issue tagged with: meeting

**Metadata Update from @sgallagh**: - Issue tagged with: meeting

music commented

2024-08-21 20:13:08 +00:00

Author

It should be noted that uv upstream seems to be documenting breaking changes very fastidiously. For the 0.3.0 release, they list:

Migrate to XDG and Linux strategy for macOS directories
Move concurrency settings to top-level
Apply system Python filtering to executable name requests
Remove --legacy-setup-py command-line argument
Stabilize preview features

They also note that the “uv pip interface should not be affected by any breaking changes.”

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.

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.

Since uv was introduced to Fedora about three weeks ago, there are a handful of packages that do depend on it.

The Python dependency checker fawltydeps can optionally use uv pip instead of pip resolve dependencies.
The Python build frontend python-build wants to run integration tests against both pip and uv pip, and since uv is available, the uv integration tests were enabled.
The Python project manager hatch requires uv as a hard dependency since upstream release 1.10.0, released 2024-05-01. Hatch upstream committed to uv early; that dependency is really baked into the design at this point, and is not removable by downstream patching.

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.

It should be noted that `uv` upstream seems to be documenting breaking changes very fastidiously. For the 0.3.0 release, they list: - Migrate to XDG and Linux strategy for macOS directories - Move concurrency settings to top-level - Apply system Python filtering to executable name requests - Remove `--legacy-setup-py` command-line argument - Stabilize preview features They also note that the “`uv pip` interface should not be affected by any breaking changes.” 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`. 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. ----- Since `uv` was introduced to Fedora about three weeks ago, there are a handful of packages that do depend on it. - The Python dependency checker `fawltydeps` can optionally use `uv pip` instead of `pip` resolve dependencies. - The Python build frontend `python-build` wants to run integration tests against both `pip` and `uv pip`, and since `uv` is available, the `uv` integration tests were enabled. - The Python project manager `hatch` requires `uv` as a hard dependency since upstream release 1.10.0, released 2024-05-01. Hatch upstream committed to `uv` early; that dependency is really baked into the design at this point, and is not removable by downstream patching. 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.

churchyard commented

2024-08-21 20:22:28 +00:00

I'd also like to solicit @churchyard 's opinion here.

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.

> I'd also like to solicit @churchyard 's opinion here. 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.

zbyszek commented

2024-08-21 21:05:16 +00:00

Owner

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

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

gotmax23 commented

2024-08-21 21:53:12 +00:00

Owner

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.

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

sgallagh commented

2024-08-22 13:46:01 +00:00

Owner

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.

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

zbyszek commented

2024-08-22 14:55:54 +00:00

Owner

But if the API is declared stable, then what's the point of forbidding upgrades?

sgallagh commented

2024-08-22 15:06:18 +00:00

Owner

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.

gotmax23 commented

2024-08-22 16:10:52 +00:00

Owner

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.

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

music commented

2024-08-22 18:29:11 +00:00

Author

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.

I have no objection to this stipulation.

> 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. I have no objection to this stipulation.

kevin commented

2024-08-24 00:37:46 +00:00

Owner

+1 to @gotmax23 's proposal

salimma commented

2024-08-24 03:08:53 +00:00

Owner

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

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

sgallagh commented

2024-08-28 12:29:32 +00:00

Owner

TOPIC: #3262 Permanent Updates Policy exception for uv
(@sgallagh:fedora.im, 17:03:41)
- AGREED: The "uv" package is granted a permanent stable updates
  exception (+7, 0, -0) (@sgallagh:fedora.im, 17:14:51)

* TOPIC: #3262 Permanent Updates Policy exception for uv (@sgallagh:fedora.im, 17:03:41) * AGREED: The "uv" package is granted a permanent stable updates exception (+7, 0, -0) (@sgallagh:fedora.im, 17:14:51)

sgallagh commented

2024-08-28 12:29:32 +00:00

Owner

Metadata Update from @sgallagh: