On 9/24/24 6:03 AM, Miro Hrončok wrote:

Hi Miro,

Thanks for bringing this up! I do agree that the widespread usage of long-deprecated setuptools functionality in Fedora packages is a problem.

Considering the fact that 1.6k Python packages use the macros (while 2k use the %pyproject_ ones), we are in for a lot of trouble when setuptools removes the support for setup.py build/install.
Indeed.
To prevent such disaster I'd like to:

 - emit loud deprecation warnings from the macros, possibly with 10 sec sleep

I definitely support emitting `%{warn:}` deprecation warnings. I like the env var escape hatch that the proof-of-concept PR (I'll try to review the POC in more detail later) implements. I am very much against stalling RPM parsing by 10 seconds like this, though, especially without a definite deprecation date set by upstream.

 - officially disallow https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/

EPEL 8 compatibility remains an issue there. We should consider implementing some version of the pyproject macros to exist in EPEL 8 that support Python 3.6, even if it's just a stripped-down version that builds wheels, installs them, and writes `%{pyproject_save_files}`, while still requiring manual BuildRequires. We can call PEP 517 hooks directly and bypass the old python3.6-pip in RHEL if need be.

Later, I'd like to experiment with https://github.com/packit/specfile to write a minimal automatic convertor from the old macros to the new. It won't be perfect and likely won't be able to ditch any manually listed BuildRequires at first, but at least it might allow us to mass update spec files while keeping them buildable.
I think this would be best presented as a tool that maintainers can use to help them convert their packages to the new macros while still requiring manual verification. I am against a bot/script sending a bunch of minimally tested PRs unless we're at a point where deprecation is very imminent and packagers have not taken action—although at that point, package retirement might be the better option.

—Maxwell

--
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to