When there is no wheel in %{_pyproject_wheeldir}, %pyproject_install fails (expected), but the failure is quite cryptic: ... + cd Pello-1.0.4 ++ ls '/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir/*.whl' ++ xargs basename --multiple ++ sed -E 's/([^-]+)-([^-]+)-.+\.whl/\1==\2/' ls: cannot access '/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir/*.whl': No such file or directory basename: missing operand Try 'basename --help' for more information. + specifier= + TMPDIR=/builddir/build/BUILD/Pello-1.0.4/.pyproject-builddir + /usr/bin/python3 -m pip install --root /builddir/build/BUILDROOT/python-pello-1.0.4-1.fc40.x86_64 --prefix /usr --no-deps --disable-pip-version-check --progress-bar off --verbose --ignore-installed --no-warn-script-location --no-index --no-cache-dir --find-links /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir Using pip 23.2.1 from /usr/lib/python3.12/site-packages/pip (python 3.12) ERROR: You must give at least one requirement to install (maybe you meant "pip install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?) error: Bad exit status from /var/tmp/rpm-tmp.1kfx77 (%install) As you can see, the last relevant error message is: ERROR: You must give at least one requirement to install (maybe you meant "pip install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?) This is of course not up to the user of our macros, they don't invoke pip directly. The actual problem is hidden a couple of lines earlier: ls: cannot access '/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir/*.whl': No such file or directory basename: missing operand This causes our shell code in the macro to pass no positional argument to pip install. We should explicitly fail when this happens with an actionable error message. Reproducible: Always Steps to Reproduce: 1. Take the example specfile from Python packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_example_spec_file 2. Remove the %pyproject_wheel line 3. Build the package Actual Results: Build fails, the error message is cryptic and not actionable, actual error buried in the log. Expected Results: Build fails, the error message is understandable and actionable, the error message is as late in the log as possible.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/428
FEDORA-2023-5c3c30efe7 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5c3c30efe7
FEDORA-2023-5c3c30efe7 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-36695c32fa has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-36695c32fa
FEDORA-2023-d2fed10480 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d2fed10480
FEDORA-2023-36695c32fa has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-36695c32fa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-36695c32fa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-d2fed10480 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d2fed10480` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d2fed10480 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-36695c32fa has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-d2fed10480 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.