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