As more and more packages move to pryproject macros we keep getting issues with the upstream metadata being sometimes too restrictive with no good reason, e.g. setting an upper bound for a dependency on an imaginary future version, requiring a very specific version only or simply just pinning the last version they tested which could be very outdated. Hence packagers resort to sed-ing or patching the problematic metadata from the various files, cluttering the SPEC files and making things brittle for every rebase when the metadata is updated. I propose the addition of an "-S" aka "set" flag which would allow packagers to set/modify/transform/tweak/adjust/alter/filter the resulting requirements. We can bikeshed on the various naming schemes. Providing here some examples on how this feature could work: Removing upper and lower bounds %pyproject_buildrequires -S pkg:remove_upper %pyproject_buildrequires -S pkg:remove_lower %pyproject_buildrequires -S pkg:remove_all Changing bounds %pyproject_buildrequires -S pkg:change_upper:4.0 %pyproject_buildrequires -S pkg:change_lower:1.5.4 Remove the package entirely from deps %pyproject_buildrequires -S pkg:ignore Multiple packages %pyproject_buildrequires -S pkg1:remove_upper -S pkg2:change_upper:3.0 Change deps generation from a specific file %pyproject_buildrequires requirements.txt -S pkg:remove_upper Multiple flags compatibility %pyproject_buildrequires -N requirements.txt -S pkg:remove_upper %pyproject_buildrequires -R -S pkg:remove_upper %pyproject_buildrequires -t -x testing -g docs -S pkg:remove_upper Reproducible: Always
An additional application for this functionality would be where a single source RPM is used to build several closely-related wheels and several python3-* subpackages. This is not well-supported by the pyproject-rpm-macros, and one-source-package-per-PyPI-project tends to be easier when it is practical. Still, such multi-wheel packages are feasible, already exist in Fedora, and are sometimes the least unpleasant option for packaging certain projects. An idiosyncratic example (with, among other oddities, a weird, customized build system controlled by environment variables) is python-typer. The python-fastapi and fastapi-cli packages are similar. Another, less peculiar examples is the python-py-key-value package, now under review in bug 2427769. Typically, one finds that some of the wheels generate runtime dependencies on each other, and these need to be filtered out so that the source package does not have an unnecessary bootstrapping loop on itself. See https://bugzilla.redhat.com/show_bug.cgi?id=2427769#c3 for one workaround, and the following comment for the reason it may be brittle. This proposal would be a much better option.
(In reply to Ben Beasley from comment #1) > An additional application for this functionality would be where a single > source RPM is used to build several closely-related wheels and several > python3-* subpackages. This is not well-supported by the > pyproject-rpm-macros, and one-source-package-per-PyPI-project tends to be > easier when it is practical. Still, such multi-wheel packages are feasible, > already exist in Fedora, and are sometimes the least unpleasant option for > packaging certain projects. > > An idiosyncratic example (with, among other oddities, a weird, customized > build system controlled by environment variables) is python-typer. The > python-fastapi and fastapi-cli packages are similar. Another, less peculiar > examples is the python-py-key-value package, now under review in bug 2427769. > > Typically, one finds that some of the wheels generate runtime dependencies > on each other, and these need to be filtered out so that the source package > does not have an unnecessary bootstrapping loop on itself. See > https://bugzilla.redhat.com/show_bug.cgi?id=2427769#c3 for one workaround, > and the following comment for the reason it may be brittle. This proposal > would be a much better option. I (plus AI), implemented the change here: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/564 Feel free to chime in the PR. It adds a -D flag to %pyproject_buildrequires with actions: remove_upper, remove_lower, remove_all, change_upper:VERSION, change_lower:VERSION, ignore. e.g.: %pyproject_buildrequires -D cython:remove_upper -D numpy:change_upper:2.0 This only works for BuildRequires however. The RPM generators grab the runtime requirements from the upstream metadata and it's a different mechanism, so you can consider the current change as Phase 1. If the overridden package is also a runtime dependency, the build will error out and prompt for patching the metadata. I plan to work on the runtime requires as well after it, which will need to touch on python-rpm-generators also. The -D ignore implemented in this PR should work for your usecase when the next phase gets implemented.
Please provide feedback here: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/745UW6JJTIAMQKDWYQRJQZ2E3VN74HO7/