Spec URL: https://music.fedorapeople.org/python-uv-build.spec SRPM URL: https://music.fedorapeople.org/python-uv-build-0.6.12-1.fc41.src.rpm Description: This package is a slimmed down version of uv containing only the build backend. Fedora Account System Username: music I plan to add all of the co-maintainers of the uv package (rust-sig, python-packagers-sig, and churchyard) to this package. This package is ultimately built from the same source tree as uv, i.e. https://github.com/astral-sh/uv, and belongs to the same cargo workspace. I choose not to build uv-build from the uv source package because this spec file can be much simpler than the one for uv, because the separation helps to keep track of which patches, licenses, additional sources, etc. apply to uv-build, and because – while it normally makes sense to synchronize updates of this package with uv updates – there will likely be times when we want to keep updating uv (primarily a developer tool) while holding uv-build (primarily used for building packages) at an older version for compatibility. The overall design and style of the spec file is based very closely on the one for uv, originally reviewed in bug 2299712. I am not aware of any upstreams that have adopted the uv backend yet. As long as there isn’t any pressure from the Fedora side to ship this in stable releases, I might keep this package Rawhide-only for a while to give the community some time to try out the build backend. If I ship this in stable releases now, and there ends up being a future (SemVer-incompatible) 0.7.x release with significant fixes to the build backend, I might wish I had waited a little longer.
Taking this review, will take a first look later today.
Copr build: https://copr.fedorainfracloud.org/coprs/build/8860387 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2357473-python-uv-build/fedora-rawhide-x86_64/08860387-python-uv-build/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
$ rpm -qlp --licensefiles python3-uv-build-0.6.12-1.fc43.x86_64.rpm /usr/lib64/python3.13/site-packages/uv_build-0.6.12.dist-info/licenses/LICENSE-APACHE /usr/lib64/python3.13/site-packages/uv_build-0.6.12.dist-info/licenses/LICENSE-MIT /usr/share/licenses/python3-uv-build/LICENSE-APACHE /usr/share/licenses/python3-uv-build/LICENSE-MIT /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/version-ranges/LICENSE /usr/share/licenses/python3-uv-build/LICENSE.dependencies FWIW you might replace %license LICENSE-APACHE LICENSE-MIT with %pyproject_save_files -l
(In reply to Miro Hrončok from comment #3) > FWIW you might replace %license LICENSE-APACHE LICENSE-MIT with > %pyproject_save_files -l Thanks. I don’t think that I remembered maturin supported PEP 639. On the other hand, I’m tempted to retain the duplicate license files, because it seems weird to have a /usr/share/licenses/python3-uv-build/ that contains the licenses for bundled libraries and statically-linked dependencies, but *not* the licenses for the package itself.
In general, the package looks good to me. I just have some non-blocking comments, suggestions for improvements, and potential questions for upstream. The only "blocking" thing that you need to resolve before importing the package would be to add ExcludeArch for i686, the package doesn't build there. ================================================================================ (0. It's a bit funny to see almost 200 lines of "setup" but then have the actual %build, %install, %check, and %files as essentially just boilerplate. :)) 1. ron 0.9.0 is actually out: https://crates.io/crates/ron/0.9.0 So this comment is no longer entirely accurate. It's still *somewhat* accurate, because we don't ship ron 0.9.0 yet, and I don't even know if 0.9.0-alpha would be compatible with 0.9.0 final - so it mightn't even help if we did. > # Downstream-only: Revert "feat: ensure successful round-trip of RON (#193)" > # This reverts commit 21c6a215432fea9a75b7d15d9a9936af9ccc17cb. > # We will not be packaging an alpha version of rust-ron. We can adjust this > # after ron 0.9.x is released. 2. I don't understand why pep440_rs and pep508_rs being only "passively maintained" is ... a problem, apparently? Or how they determined that they even *are* "passively maintained"? They have regular releases, and even their other project (astral-sh/ruff) still depends on them. I also don't see anywhere these crates are marked as "passively maintained" - there's a [badges] section in Cargo.toml that can contain maintenance status like that, but it's not set in either of these two crates. So maybe this is ill-informed or based on outdated information? 3. This reads a bit like getopt-salad, and I don't claim to understand what half these flags do: > %setup -q -T -D -b 200 -n uv_build-%{version} > %autopatch -p1 -m200 -M299 But I'm assuming they do what they're supposed to, because the build works :) I would definitely need to read the RPM documentation to understand what's going on, though. 4. I'm assuming there are no "Python" tests, i.e. runnable from pytest (or similar)? Then just running %cargo_test is fine. 5. Note that if you ever want to build this crate for old branches (like EPEL 9), you will need to "export RUSTFLAGS=%{build_rustflags}" or similar, because %set_build_flags only sets RUSTFLAGS on recent branches of Fedora (and I think in EPEL 10, but I'm not even sure about that). 6. You might need to add "ExcludeArch: %{ix86}" to this package. I launched a scratch build, and it failed on i686. 7. There's duplicate files warning from rpmlint, but that is probably unavoidable (license files bundled in pep440_rs and pep508_rs being identical). But it would be good to address the duplicates mentioned by Miro in the previous comment. 8. There is no manpage shipped (not a problem), and the explanation why it doesn't even really make sense to include one (executable only invoked by other programs, not by users directly) is documented. ================================================================================ Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [x]: Package must own all directories that it creates. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 216 bytes in 1 files. [x]: Packages must not store files under /srv, /opt or /usr/local Python: [x]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: python3-uv-build-0.6.12-1.fc43.x86_64.rpm python-uv-build-0.6.12-1.fc43.src.rpm python3-uv-build.x86_64: W: no-manual-page-for-binary uv-build python3-uv-build.x86_64: W: files-duplicate /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-Apache python3-uv-build.x86_64: W: files-duplicate /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-BSD 2 packages and 0 specfiles checked; 0 errors, 3 warnings, 11 filtered, 0 badness; has taken 0.4 s Rpmlint (installed packages) ---------------------------- python3-uv-build.x86_64: W: no-manual-page-for-binary uv-build python3-uv-build.x86_64: W: files-duplicate /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-Apache python3-uv-build.x86_64: W: files-duplicate /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-BSD 1 packages and 0 specfiles checked; 0 errors, 3 warnings, 5 filtered, 0 badness; has taken 0.1 s Source checksums ---------------- https://github.com/astral-sh/pubgrub/archive/b70cf707aa43f21b32f3a61b8a0889b15032d5c4/pubgrub-b70cf707aa43f21b32f3a61b8a0889b15032d5c4.tar.gz : CHECKSUM(SHA256) this package : 64b53dc8b30240d6636cab321750f786e7f50594f0403a1f96b6e8e235014d0a CHECKSUM(SHA256) upstream package : 64b53dc8b30240d6636cab321750f786e7f50594f0403a1f96b6e8e235014d0a https://files.pythonhosted.org/packages/source/u/uv_build/uv_build-0.6.12.tar.gz : CHECKSUM(SHA256) this package : 0a096d8de959ffd20efd1bbb8e4621b511bf8d960f265d418b1a9ec0599781c8 CHECKSUM(SHA256) upstream package : 0a096d8de959ffd20efd1bbb8e4621b511bf8d960f265d418b1a9ec0599781c8 Requires -------- python3-uv-build (rpmlib, GLIBC filtered): libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libm.so.6()(64bit) python(abi) rtld(GNU_HASH) Provides -------- python3-uv-build: bundled(crate(pep440_rs)) bundled(crate(pep508_rs)) bundled(crate(version-ranges)) python-uv-build python3-uv-build python3-uv-build(x86-64) python3.13-uv-build python3.13dist(uv-build) python3dist(uv-build)
Thank you for the review! https://release-monitoring.org/project/377550/ (In reply to Fabio Valentini from comment #5) > The only "blocking" thing that you need to resolve before importing the > package would be to add ExcludeArch for i686, the package doesn't build > there. Good observation. > ============================================================================= > === > > (0. It's a bit funny to see almost 200 lines of "setup" but then have the > actual %build, %install, %check, and %files as essentially just boilerplate. > :)) > > 1. ron 0.9.0 is actually out: > > https://crates.io/crates/ron/0.9.0 > > So this comment is no longer entirely accurate. It's still *somewhat* > accurate, because we don't ship ron 0.9.0 yet, and I don't even know if > 0.9.0-alpha would be compatible with 0.9.0 final - so it mightn't even help > if we did. I had noticed that. It’s on my medium-term TODO list to investigate updating the rust-ron package in Fedora (so I’m not caught unprepared once I start asking for changes upstream), then send a PR to https://github.com/pubgrub-rs/pubgrub/ to update the ron dev-dependency to 0.9.0 final, then ask https://github.com/astral-sh/pubgrub to pull the change into their fork. Once that’s all done, and uv upstream updates the git dependency on the astral pubgrub fork, I’ll finally be able to drop the ron-related patches from uv and python-uv-build. None of that should be too difficult, but it will take a while to work through the whole process. I decided to leave the comment as-was rather than adding a lot of detail about the process of removing the patch. > 2. I don't understand why pep440_rs and pep508_rs being only "passively > maintained" is ... a problem, apparently? Or how they determined that they > even *are* "passively maintained"? > > They have regular releases, and even their other project (astral-sh/ruff) > still depends on them. I agree that the “passively maintained” characterization doesn’t seem to be accurate. On the other hand, I just spot-checked the source diff between src/ in https://github.com/konstin/pep440-rs and uv/crates/uv-pep440/src/ in https://github.com/astral-sh/uv, and the part of upstream’s rationale where they say that the "uv-" implementations “have diverged significantly” from the standalone/crates.io ones does seem to be quite accurate. It’s hard to see the two implementations being reconciled at this point. > 3. This reads a bit like getopt-salad, and I don't claim to understand what > half these flags do: > > > %setup -q -T -D -b 200 -n uv_build-%{version} The flags for using %setup with multiple sources are *awful*. This is basically the recipe in "Using %setup in a Multi-source Spec File" from http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html. It’s extracting Source200, resulting in pubgrub-b70cf707aa43f21b32f3a61b8a0889b15032d5c4/ as a sibling of uv_build-0.6.12/ from Source0, and then we end up back inside uv_build-0.6.12/. It would probably be easier to just invoke tar manually, but this works as advertised, and is actually much less fancy than it appears. > > %autopatch -p1 -m200 -M299 This is applying patches numbered 200-299, inclusive. The scheme of numbering extra source archives as 100, 200, 300, and so on, and then numbering patches for those archives as 100-199, 200-299, 300-399, and so on, respectively, is carried over from uv. There, it really helps cut down on confusion about which patches go with which sources. Here, there is only one extra archive, and there is no Source100 because pubgrub/version-ranges is Source200 in uv, and making the numbers match helps avoid unnecessary differences between the two spec files and make it easier to compare them. > 4. I'm assuming there are no "Python" tests, i.e. runnable from pytest (or > similar)? Then just running %cargo_test is fine. Right. > 5. Note that if you ever want to build this crate for old branches (like > EPEL 9), you will need to "export RUSTFLAGS=%{build_rustflags}" or similar, > because %set_build_flags only sets RUSTFLAGS on recent branches of Fedora > (and I think in EPEL 10, but I'm not even sure about that). Checking EPEL 10, I don’t see RUSTFLAGS in the expansion of %set_build_flags, but in a test build, I neverthless do see it getting set in %build. This will still be something to remember if we ever manage to branch maturin in EPEL 9. > 6. You might need to add "ExcludeArch: %{ix86}" to this package. I launched > a scratch build, and it failed on i686. Good catch. The original uv submission had a patch to build on i686, but it was removed based on review feedback (basically: why bother?). I guess it would make sense to start out with ExcludeArch here, although it seems like every time I try to exclude i686 in a Python library package, I’m painted into a corner by shifting dependencies and I end up restoring i686 support later. Hopefully that doesn’t happen here. I would rather not build an i686 package if I don’t have to. > 7. There's duplicate files warning from rpmlint, but that is probably > unavoidable (license files bundled in pep440_rs and pep508_rs being > identical). But it would be good to address the duplicates mentioned by Miro > in the previous comment. I still think that it is weird to have a /usr/share/licenses/python3-uv-build/ that contains the licenses for bundled libraries and statically-linked dependencies, but *not* the licenses for the package itself. Still, I’ll defer to the two votes in favor of omitting the duplicates.
The Pagure repository was created at https://src.fedoraproject.org/rpms/python-uv-build
FEDORA-2025-85355472f3 (python-uv-build-0.6.12-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-85355472f3
FEDORA-2025-85355472f3 (python-uv-build-0.6.12-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
%cargo_license_summary %{cargo_license} > LICENSE.dependencies If you run this before %pyproject_wheel, will the file be included in dist-info/licenses?
(In reply to Miro Hrončok from comment #10) > %cargo_license_summary > %{cargo_license} > LICENSE.dependencies > > If you run this before %pyproject_wheel, will the file be included in > dist-info/licenses? Yes, that does work. That would leave only the contents of LICENSE.bundled/ to be handled manually. /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep440_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-Apache /usr/share/licenses/python3-uv-build/LICENSE.bundled/pep508_rs/License-BSD /usr/share/licenses/python3-uv-build/LICENSE.bundled/version-ranges/LICENSE I *could* give these each unique names, like LICENSE.pep440_rs.License-Apache, to flatten the directory structure, and then they could be automatically included too. There are not nearly as many of these files as there are in the full uv, so this would be tractable. I’ll mull whether or not doing so is a good idea.
Or we can see if maturing supports this: [project] license-files = ["LICENSE*", "LICENSE.bundled/*"]
(In reply to Miro Hrončok from comment #12) > Or we can see if maturing supports this: > > [project] > license-files = ["LICENSE*", "LICENSE.bundled/*"] I just tried that, and it doesn’t seem to change anything.