Please branch and build python37 (v3.7.5) for EPEL 7 + CentOS 7.
According to  and , Fedora 30 and 31 have python 3.7.5 in the python3 rpm.
According to  Fedora 32 has python 3.7.5 in the python37 rpm.
But the search in  finds no python37 packages.
I couldn't figure out how to find the maintainer email address to ask them to branch as instructed in , so I'm filing this request here.
Hi Jacob and thanks for the request.
Unfortunately I am currently quite busy with maintaining the system python interpreter along with the alternative interpreters on various branches. I believe that would be the same for the rest of the python-sig members. Would you be willing to maintain the interpreter and keep it in good state for the epel7 branch? I am cc'ing Carl George as well, he might be interested into that, I understand he is quite busy as well though.
I am not prepared to help with EPEL packaging.
What kind of time commitment does it take to maintain a branch of python like this?
A very long term commitment. Life time of EPEL is > decade, EPEL 7 will continue several years after Python 3.7 will been unsupported upstream.
See the linked thread.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.
For posterity, here are the EOL dates in question.
2021-12: Python 3.6 
2023-06: Python 3.7 
2024-06: RHEL 7 and EPEL 7 
2024-10: Python 3.8 
2029-05: RHEL 8 and EPEL 8 
Considering how the dates fall, and the fact that Red Hat will be maintaining python38 in RHEL 8 , I think it would make more sense to shift the spirit of this request from 3.7 to 3.8. This will be relatively straightforward once Miro's recent proposal on python-devel  is implemented. Would anyone be opposed to me transferring this bug to the python38 bugzilla component and changing the title?
If RHEL 8 already includes a Python 3.8 module, why would EPEL 8 need Python 3.8?
> If RHEL 8 already includes a Python 3.8 module, why would EPEL 8 need Python 3.8?
This request is about EPEL 7.
python38 in EPEL 7 would satisfy me.
(In reply to Carl George from comment #6)
> For posterity, here are the EOL dates in question.
> 2021-12: Python 3.6 
> 2023-06: Python 3.7 
> 2024-06: RHEL 7 and EPEL 7 
> 2024-10: Python 3.8 
> 2029-05: RHEL 8 and EPEL 8 
> Considering how the dates fall, and the fact that Red Hat will be
> maintaining python38 in RHEL 8 , I think it would make more sense to
> shift the spirit of this request from 3.7 to 3.8.
I don't disagree with that, but I expect that more than trying to determine the "appropriate python version out of the Hat". My interpretation is that some end-users instead want a deterministic and reliable way to have "current" python on their enterprise OS. (even if with partial support or minimal/incomplete stack).
So that end-users CI (or others uses-cases) can pick all ranges of python versions they want (like they can pick all ranges of PHP versions already , thanks Remi).
As a Fedora maintainer, I would advertise to use Fedora with the appropriate python, then some Fedora versions might not be supported the same as the given python.
For Enterprise users/needs, it would be easier to also have some python39 available at some point (only for EL8 as CentOS Stream/EPEL).
(Side note, I'm just trying to "interpret" the request, not assume any resources to do the job in any way yet).
Given the current state of things (e.g. Python 3.9 in ELN), may I suggest to repurpose this bugzilla for Python 3.9?
I'd gladly help with the initial spec file, but if people want to build packages against Python 3.9/3.8, somebody else has to drive the Python 3.4 removal. I'm also afraid that if packagers simply start building from current EPEL 7 components, many ancient versions won't even support Python 3.9 (or 3.8).
There is a rh-python38 available as scl, so I guess the issue can be closed.
Please re-consider adding python38 to EPEL 7. Or at least uwsgi-plugin-python38 for compatibility with either rh-python38 or EPEL python38.