This simply defines %generate_buildrequires to %{nil} to allow that to remain in specs. Not sure if this is good or if it should error out

IMHO this is a bad idea. Better do not define that at all and allow packagers to explicitly use something like:

%{?pyproject_buildrequires:
%generate_buildrequires
%pyproject_buildrequires -...
}

By defining %generate_buildrequires to %nil a Fedora specfile will silently produce bad results on EPEL 8. When %generate_buildrequires comes after %prep it would simply echo all the buildrequires to stdout and do nothing. However, I've seen multiple packagers that would stick the %generate_buildrequires section before %description (next to the manual BuildRequires) . That would make the specfile unparseable I think.

I've commented out running pyproject_buildrequires.py because %{buildsubdir} is not defined in %prep and we get a top level .pyproject-build directory

(I moved this here, as it is related.) I think that running %pyproject_buildrequires without %generate_buildrequires at all makes no sense. Better to remove that macro entirely. If need to be, it must run at the beginning of %build.

I'm getting recursive copy failures with TMPDIR=%{_pyproject_builddir}. Not sure what the ramifications of leaving that out are

Ramifications: Missing debuginfo. Try building a package with an extension module.

This is https://github.com/pypa/pip/issues/7872 fixed in https://github.com/pypa/pip/pull/7873 -- if you would like to open a PR in CentOS Stream 8 with a backport, I would gladly review it.

I don't understand with MANPATH needs to be empty but that is what the test output says

The test naïvely parses a shell script with regular expression. The idea is that if it fails entirely, the parsing needs to be changed. It's a simple regression test to let us know that the script in RPM is different. See https://github.com/rpm-software-management/rpm/blob/rpm-4.18.0-alpha2/scripts/brp-compress#L16 vs https://github.com/rpm-software-management/rpm/blob/rpm-4.14.3-release/scripts/brp-compress#L14 and change https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/compare_mandata.py#_19 accordingly.

Why does this force the Python version to 3.8? This should be useable with e.g. 3.9 as well.

I've uploaded a branch for python3x-pip here: https://git.centos.org/fork/orion/rpms/python3x-pip/tree/pip7873 but I seem to be unable to generate a PR from that - pagure seems to error out with all of my options.

I've dropped %generate_buildrequires and %pyproject_buildrequires.

I've tried to make it compatible with python 3.9 as well.

but I seem to be unable to generate a PR from that - pagure seems to error out with all of my options.

It's possible to construct the URL manually (https://git.centos.org/fork/orion/rpms/python3x-pip/diff/c8s-stream-3.8..pip7873), but my understanding is that the proper way to submit c8s patches was through Bugzilla.

We need a bugzilla for processing the request either way, but a Pagure PR is easier to review (despite me not being able to merge it at the end).

I am not entirely sure I understand the need to replace all occurrences of %__python3 with %__pyproject_python. What is the idea here?

I have the bad habit of building packages locally without the proper python3X-rpm-macros installed. I've dropped that change now.

Is there a reason this is using python3.8 instead of the default Python?

I suspect pip for 3.6 is too old to handle any of this.

correct

I have branched python38-toml-epel and added python-sig and epel-packagers-sig as co-maintainers.

Just curious. Why is the component name python38-toml-epel and not python-toml-epel to allow building for more Pythons or python38-toml since that component does not exist in RHEL?

Just curious. Why is the component name python38-toml-epel and not python-toml-epel to allow building for more Pythons or python38-toml since that component does not exist in RHEL?

On epel-devel[1], we decided to name them like this. This python38-toml-epel naming makes it easier to convert Fedora specfiles (the actual binary rpm is still a subpackage), makes it clear that it's EPEL only, differentiates it from the python-toml source package which is already packaged for EPEL 8, and allows us to package it for python39 if needed. If you think they should be named otherwise, you're welcome to chime in :).

[1]: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/S4KRUJZNDKRFHUQMNJWR6TIGGDBAPM7L/ and the following messages

Thanks for the pointer.

My experience with python36/38 for EPEL7 led me to prefer the split. The 36 version of a package would be limited by python or other other deps. Having a separate python38 package allowed for newer versions to be used. I suspect we'll see the same in EL9 as more python versions get added.

That makes perfect sense, agreed. Also, we would need the "other" set of macros again and that is not manageable. I was more curious about why both "38" and "epel" in the name but now I got it, so it can remain a subpackage.

The "epel" also makes it explicit that these are epel only packages. I get bugs filed against my python3-X EPEL packages for Fedora issues.

We still need to package tox and tox-current-env for python38 and python39 and update the epel-rpm-macros %py3_check_import backport, as %pyproject_check_import uses a flag that the current implementation does not support. However, I'm not super convinced that the former is worth the effort. Isn't one of the main selling points of the %tox macro is that it works together with %pyproject_buildrequires -t to result in less work for packagers?

For the record, I'm not super convinced that this entire effort is worth the effort. One of the main selling points of pyproject-rpm-macros is %pyproject_buildrequires :)

For the record, I'm not super convinced that this entire effort is worth the effort. One of the main selling points of pyproject-rpm-macros is %pyproject_buildrequires :)

I agree with your latter point, but I think it's still useful for packages that don't have setup.pys and therefore don't work with %py3_build and friends. Also, maintainers who use pyproject-rpm-macros would only have to conditionalize %pyproject_buildrequires (or just not use it) and manually specify BRs, while the rest of the spec could stay the same between Fedora and EPEL. I think having even part of pyproject-rpm-macros supported on EPEL 8 could help increase adoption amongst packagers who build for EPEL 8 and want to mainain a single specfile. At least in my case, ansible still uses the old macros, but I'd likely convert it to the new ones for all releases if they became available on EPEL 8.

Also, we would need the "other" set of macros again and that is not manageable.

Can you expand on why that is not manageable? @ignatenkobrain was asking me about why the %py3_other_* macros weren't an option for alternative python stack packaging on epel8, but I wasn't aware of the history and have never done epel7 packaging.

Also, I was able to build this successfully with the tests enabled after patching compare_mandata.py and removing all of the %tox and %pyproject_buildrequires stuff (I removed that first and didn't check if it any of those tests worked). I still would like to do some more testing and cleanup before submitting, but feel free to look at the COPR or my fork in the meantime.

Closing in favor of the newer https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/297