I would very much like to branch and build uv in EPEL9 (and EPEL10!). Unfortunately, it won’t be possible in the short term.

You’re correct that the spec file uses rust2rpm-helper at build time, which is kind of unusual but very helpful – so rust2rpm-helper would need to be branched. So would dozens of Rust crate library dependencies. None of that is a real problem.

The real issue with building uv in EPEL9/EPEL10 is that uv’s MSRV (minimum supported Rust version) is currently 1.81, which is the latest version of Rust. So far, each time a new release of Rust appears, uv has started using new Rust features within a couple of weeks. Fedora can keep up with this, since the Rust toolchain is updated promptly in all branches, but EL9 currently has Rust 1.75 and EL10 currently has Rust 1.79.

The only possibility I see is that a future point release of the distribution may update the Rust toolchain to something new enough that I can package a not-quite-current but still useful version of uv at some point in the future, and then accept that I will not be able to update it until and unless the Rust toolchain is updated again.

As it stands, uv is new enough, and development is moving fast enough, that there isn’t a viable version of uv that would compile with Rust 1.75, and even Rust 1.79 puts you before the 0.4.0 release, which introduced a lot of major functionality[1].

I’ll assign this bug and leave it open for tracking purposes even though no progress can be made right now.

[1] https://github.com/astral-sh/uv/releases/tag/0.4.0

Thank you so much for the detailed explanation which is totally reasonable.

Is it possible to package an alternate rust version to a non-conflicting path?

(In reply to Miro Hrončok from comment #3)
> Is it possible to package an alternate rust version to a non-conflicting
> path?

I don’t know, but the rest of the Rust SIG is CC’d on this bug, so maybe someone will chime in.

If an alternate Rust *is* possible, and if someone is willing to maintain it, then the next question is whether it would be possible to use system packages for Rust crate library dependencies that were packaged for the main/system Rust.

The dependency tree for uv is large, and many dependent crates have patches for things like missing license texts. If using an alternate Rust toolchain would mean vendoring all dependencies, then it would be necessary to repeat all of this auditing and patching work. That’s more duplicated effort than I’m willing to sign up for. Helping keep uv’s dependencies up to date in Fedora is already a significant fraction of my packaging work overall. I guess uv with all dependencies vendored could still be possible, but it would have to be Someone Else’s Problem.

On the other hand, if I would only have to vendor the dependencies that have an MSRV too new for the system Rust, then that might be possible – this should be no more than about a dozen crates at the moment. If that turns out to be the case, then I would at least be willing to invest some time trying to work up a proof of concept.

For the record, I am brainstorming ideas for a technical solution. In no way I am suggesting it should be done and who should do it :)

> then the next question is whether it would be possible to use system packages for Rust crate library dependencies that were packaged for the main/system Rust.

I don't think using the packaged crates would be a problem.

However, we'd need to add support for an "alternative toolchain" to rust-packaging / cargo-rpm-macros.
They currently hard-code /usr/bin/cargo, for example.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

These are some detailed comments that I wrote in reponse to an email about this:

In the current RHEL 9, the Rust compiler is not quite new enough to build a reasonably recent version of uv, and for EPEL we need to be able to build with the system’s toolchain. This isn’t a permanent obstacle: CentOS Stream 9 has a new enough Rust, so it should already be possible (from a toolchain perspective) to build a uv package for epel9-next, and probably possible for EPEL 9 proper after the next RHEL 9 minor release.

A more serious difficulty is that uv is built using maturin, and building maturin requires python3-setuptools-rust. See https://bugzilla.redhat.com/show_bug.cgi?id=2173215#c11 regarding that. I believe I could most likely branch and build maturin for EPEL 9 (coordinating with Fabio Valentini, the primary maintainer for the maturin package) if I had a working python3-setuptools-rust, but I have not had time, and it hasn’t been a high priority for me as a volunteer, to try to validate this in COPR, nor to pursue (if necessary) the stalled EPEL package request process for python-setuptools-rust.

There are, of course, a large number of Rust library packages that would need to be branched for uv, but I have already proved most of these out in COPR, and I don’t foresee any real difficulties in that area.