On 12. 10. 24 0:32, Adam Williamson wrote:

On Fri, 2024-10-11 at 21:29 +0200, Michal Ambroz wrote:

...

Hello Miro, Thank you very much for the tool - I am adding it to toolbox.

I actually love the new pyproject macros, but in the past there were some discrepancies between Fedora and EPEL where not everywhere the situation was ready there to switch to pyproject macros. Please have you checked recently how EPEL8-9-10 is doing with the Fedora pyproject macros? Does it make sense to switch over for all current EPELs?

EPEL 8 can't use them. EPEL 9+ can. This is mentioned at the top of https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ .

On the whole I'd say it makes sense to use pyproject on all other branches and have EPEL 8 use the old guidelines, in most cases. You *probably* don't want to keep an EPEL 8 branch in sync with Rawhide anyway, we're not supposed to do major version bumps and stuff in EPEL.

Pretty much what Adam said. Some details:

Python 3.6 in RHEL 8 is probably too old to handle the Python code in pyproject-rpm-macros. This could be fixed by changes in that code of it was the only problem (it isn't).

pip 9 in RHEL 8 is too old to support pyproject-based builds. pips for newer Python versions in RHEL 8 are more capable.

setuptools 39.2 in RHEL 8 is too old to provide the (default) setuptools.build_meta:__legacy__ backend. setuptools for newer Python versions in RHEL 8 are more capable.

RPM 4.14 in RHEL 8 is too old to understand %generate_buildrequires. There is a EPEL 8 version of the pyproject-rpm-macros package, but it is severly limited because of this.

tl;dr RHEL 8 is very old. it predates the fundamental principles those macros were build on. Python packaging has evolved in the past 6 years almost beyond recognition. RHEL 8 is too old to catch up. We are at a point where we can no longer build Python RPM packages for EPEL 8 and Fedora form the same spec file, unless we fill it with %if conditionals.