Description of problem: python-build (https://pypa-build.readthedocs.io/en/stable/) implements PEP 517 which is the recommended way to build and install python packages. It would be very useful to have it packaed for EPEL 8/9 as it is already in Fedora, so that "python -m build" works out of box. Version-Release number of selected component (if applicable): Latest (0.8.0) if possible.
I just took a look at this out of curiosity. ----- For EPEL9, I tried a simple > $ fedpkg --release epel9 mockbuild using the package in Rawhide. > No matching package to install: 'python3dist(pytest) >= 6.2.4' After removing the minimum version with > sed -r -i 's/^([[:blank:]]*pytest.*)>.*/\1/' setup.cfg (something I was less worried about doing because this is only a test dependency, not a runtime dependency), I got a successful build with all tests passing. It should therefore be straightforward for someone to maintain an EPEL9 branch. I’ll wait for Lumír to say whether *they* want to do so. ----- For EPEL8, it’s harder to test, because I would have to write an “old-style” spec file without pyproject-rpm-macros. Looking at the sources and the packages that are in EL8/EPEL8 now, it looks like python-pep517 would have to be backported to EPEL8, and other dependency versions would be an issue. Some requirements would have to be loosened downstream, hopefully without breaking anything. Even packaging an old version of “build” probably wouldn’t help much here, since the current minimum dependency versions were added (https://github.com/pypa/build/commit/bb8878c5fe0b13f6b1ef416dfd93c536ed01e625) pretty early in the history of “build” development. EPEL8, therefore, would be a lot more work and a substantial chance of turning out not to be possible.
Thank you very much for your quick response! Good news for EPEL9! Unfortunately EPEL 8 is more critical for me, but thank you very much anyway for the analysis!
Hi Enrique. I'm not interested in maintaining packages in EPELs. If you want to do it, I can give you the permissions for epel* branches in dist-git. What do you think?
Hi Lumir, thank you for your answer. I could try to create RPM for EPEL 8/9 but I am not myself a Fedora developers, so I am not familiar with the Fedora procedures in this case. If you could provide me with some information that would be great.
Hi If you want to become a packager for Fedora and EPEL, you should read https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ and https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/ . You can then create a new package and get sponsored, I'm a sponsor so I can do a review of the packages and then sponsor you to the group.
Thank you very much for the info. I will have a look.
Lack of python3-build prevents Ansible DevTools team from testing packaging of ansible-lint using packit service at upstream level. While we run it for Fedora, we cannot run it for CentOS 9 Stream because there is no python3-build. That package is critical for any python project as most of them migrated to build, for building sdist and wheels. I would say that a python distribution without pip, wheel and build, is as good a broken as it would be too limited, even for development.
I agree that we should have python-build in EPEL 9, but it's not strictly necessary to package for EPEL 9. Our packaging tools use pip to build and install wheels. Developers are generally expected to use pip and venvs. If you really need to build an sdist without python-build for a setuptools based project, so you can still use the "legacy" way: add a stub setup.py (`from setuptools import setup; setup()`) and use `setup.py sdist` or run `python -c 'from setuptools; import setup; setup()' sdist`.
Adding a `setup.py` is out of question because it is known that its sole presence change behavior on lots of tools, making them switch to old behaviors at best but often causing other issues. For these reasons we will not produce centos-stream RPMs for any of Ansible DevTools projects upstream until this is sorted. We will stick to Fedora ones. Related: https://github.com/ansible/ansible-compat/pull/292
I am a fedora dev and am a member of the EPEL packagers sig (whatever the right name is) and I would like to have python-build and python-installer. (Not sure I want to be the EPEL maintainer in perpetuity, but I will at least do the initial build in EPEL9.) If you would add the EPEL packagers SIG as a collaborator then I can do a build.
I can take care of this and maintain the EPEL 9 branch going forward as a member of the Python Packagers SIG (already a co-maintainer of this package). If Lumír is ok with it, I can also add the EPEL Packagers SIG as a co-maintainer.
FEDORA-EPEL-2023-d15e89799f has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d15e89799f
FEDORA-EPEL-2023-d15e89799f has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d15e89799f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Building one package with python-build from testing did work. Both using the option -n and without. I have not tried to exercise other options. Thank you very much for providing this!
epel-packagers-sig is now a collaborator of this package for epel* branches.
FEDORA-EPEL-2023-d15e89799f has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.