Dear package maintainer, this bugzilla is automated becasue the number of impacted packages it too high to go trough manually. It appears that your package uses the deprecated %py3_build and/or %py3_install macro. See https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros for why the macros are deprecated. %py3_install expands to python setup.py install. This has been a deprecated command for 5 years and will likely stop working in Fedora 45. Please migrate to %pyproject_buildrequires + %pyproject_wheel + %pyproject_install macros instead. See https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros#Migrating_to_%pyproject_macros for migration guide. See https://github.com/hroncok/pyprojectize/ for a tool that can help you automate the migration. Thank you. Let me know if you need help.
Looks like this project does not contain a wheel file... Is that optional? ++ ls '/builddir/build/BUILD/python-pycxx-7.1.10-build/pycxx-7.1.10/pyproject-wheeldir/*.whl' ++ xargs basename --multiple ++ sed -E 's/([^-]+)-([^-]+)-.+\.whl/\1==\2/' ls: cannot access '/builddir/build/BUILD/python-pycxx-7.1.10-build/pycxx-7.1.10/pyproject-wheeldir/*.whl': No such file or directory basename: missing operand Try 'basename --help' for more information. + specifier= + '[' -z '' ']' + echo 'ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir} /builddir/build/BUILD/python-pycxx-7.1.10-build/pycxx-7.1.10/pyproject-wheeldir' ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir} /builddir/build/BUILD/python-pycxx-7.1.10-build/pycxx-7.1.10/pyproject-wheeldir + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.eW7OM6 (%install) Also, it uses `%global py_install_args...` which is not mentioned on the changes page. Is that still functional?
I'm the upstream maintainer as well as the Fedora maintainer. I release a tarball of the PyCXX code and there has never been a wheel version. The setup.py is only copying C++ Source and Include files into %{_usrsrc} and %{_includedir}, it's not a traditional use of setup.py. As long as the python distutils deps work then the setup.py will continue to work. If the distutils deps go away in the future i can refactor to use another way to copy the files into %{_usrsrc} and %{_includedir}. If the macros are the trigger for this bug, I can just stop using the macros in the .spec.
I looked at pycxx-7.1.10/setup.py and I see a custom install class. Do you know if setuptools plans to keep supporting that when they remove the setup.py install command? I see no deprecation warning in the build.log, so perhaps it will. The macros are indeed the trigger for this bug, but I also opened bugzilla for packages using setup.py install manually without macros, as calling setup.py install will stop working in setuptools released in October this year. I think the proper course of action here would be to 1. Replace the macro invocation with the direct command in case we remove the macro once the setuptools change happens. 2. Add a comment above the command explaining that this uses a custom distutils install command class. Does that work for you?
Yes, your proposal is what I was think. Especially the need for the comment explaining the plan is distutils breaks the setup.py. I'll work on this and update here once I commit a fix.