epel

#288 Discussion: making it easier to use alternate Python stacks in EPEL?
Closed: Fixed by salimma. Opened by salimma.

Closed: Fixed
Reopen Issue

RHEL/CentOS Stream ships several Python runtimes, but only one is the default. It gradually becomes harder to target - both because Python modules and apps we might want to package start making use of newer Python features, and because they gradually start using new packaging configurations

e.g. setuptools 53 in EL9 predates PEP 621 so pyproject.toml-only projects can no longer be built. In some cases (eg python-b4 0.14.0) reverting to the old setup.py is non-trivial as upstream's migration to pyproject.toml involves moving some files around as well.

There are at least three large set of packages currently stalled on setuptools:

  • mailman's Django based web stack; some components start requiring newer setuptools
  • pyside6 and a lot of Qt apps, eventually KDE too
  • Conda (which requires libmamba, newer versions of which needs newer setuptools)

Seems like we either need to make it easier to package alternate versions of key components like setuptools, or make it easier to target alternate Python runtimes.

Previous discussion: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/WNNAZWWHDU7LE4EJBDKREJO5FJQ6SXRX/

Metadata Update from @salimma:
- Issue tagged with: meeting

Not to derail the discussion, but please take the KDE6 desktop out of the conversation. I have said "No" to KDE6 coming to epel9 from the start. I might have said "maybe" once or twice, on the condition that things worked. But my investigations have brought me back to "No".

Individual applications like pyside6, sure, go for it. Let's get this fixed for them.

KDE is working on Python bindings for KDE Frameworks, so this will come up eventually.

And this also applies to EPEL 10. This problem isn't EPEL 9 only.

Yep. I'm not against this. I just saw that and worried what people were thinking about KDE.

What is a proposed way to make it easier to package the key components?

IMO, it's too complex to provide alternate versions of libraries/modules that themselves already target alternative runtime versions. For example, RHEL 9 provides these setuptools packages:

  • python3-setuptools: setuptools 53 for python 3.9
  • python3.11-setuptools: setuptools 65 for python 3.11
  • python3.12-setuptools: setuptools 68 for python 3.12

Providing alternate versions of setuptools for one or more of these would result in a confusing matrix of names (e.g. python3-setuptools65, python3.11-setuptools68, etc). I'm also not sure how we would avoid these having file conflicts with RHEL packages, which is against EPEL policy.

The libraries available in RHEL don't always facilitate providing the latest versions of software in EPEL. We have to choose versions to deliver in EPEL based on what is available to us, or what we can provide in a non-conflicting way as forward compat packages in EPEL itself.

My suggestion would be if you need a newer setuptools than 53, then you use python3.12-setuptools, which of course means building your entire package against python3.12 and making sure the rest of the libraries you need are available for python3.12.

We've discussed this last week, I don't think we need to discuss it again

Using the alternate Python stack sounds like the way to go based on the discussion in the meeting and post-meeting; I'll try and standardize the current draft of https://fedoraproject.org/wiki/EPEL/Python3X and propose it for the EPEL docs in the future and then we can retire that page

(it still refers to EPEL 8, and the conversion script it provides adds the -epel suffix unnecessarily)

Metadata Update from @salimma:
- Issue untagged with: meeting
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/288

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.