Description of problem: Please provide a subpackage with a build against python36. Version-Release number of selected component (if applicable): - How reproducible: yes Steps to Reproduce: 1. yum install python36-requests 2. 3. Actual results: no package found Expected results: python module requests properly installed for python36 Additional info: https://src.fedoraproject.org/rpms/python-pyvmomi/c/c8fe2937aaa1f50f74b30ce2670707ce53a347ea?branch=master
The first thing to decide is whether or not it's okay to update python34-requests from 2.12 to 2.20. If not, it would be better to create a new python36-requests package. I'm afraid I'm not very familiar with the history of python-requests myself to say. Nothing explicit in the history. Perhaps someone from infra-sig.org (python-requests maintainer) has some insight.
IMHO python-requests is an essential package and might be expected to get merged into python core libraries with any further version.
python3-requests-2.12.5-2.el7 python3-urllib3-1.19.1-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4004d6feae
python3-requests-2.12.5-2.el7, python3-urllib3-1.19.1-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4004d6feae
Well, like anything in epel, we have to be careful. I don't off hand know of any breakage between those versions. I think we should try and avoid seperate packages where we can for python3.
(In reply to Kevin Fenzi from comment #5) > Well, like anything in epel, we have to be careful. I don't off hand know of > any breakage between those versions. > I think we should try and avoid seperate packages where we can for python3. What's the issue with having the dedicated python version in the name of the indiviual subpackage? That's fully in compliance with the packaging policies but I agree we've no official announcement for this.
python3-requests-2.12.5-2.el7, python3-urllib3-1.19.1-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Raphael Groner from comment #6) > (In reply to Kevin Fenzi from comment #5) > > Well, like anything in epel, we have to be careful. I don't off hand know of > > any breakage between those versions. > > I think we should try and avoid seperate packages where we can for python3. > > What's the issue with having the dedicated python version in the name of the > indiviual subpackage? That's fully in compliance with the packaging policies > but I agree we've no official announcement for this. right, there's nothing against it in the guidelines, I just think is adds to confusion. Then you have python-foo (from rhel), python3-foo (that only makes the 34 version) and python36-foo (that only makes the python36 version). If at all possible it would be best to keep the number of packages down. Additionally, when say there's a python37, the python3 package could move to that and coonfuse things more. :)
(In reply to Kevin Fenzi from comment #8) > (In reply to Raphael Groner from comment #6) > > (In reply to Kevin Fenzi from comment #5) … > right, there's nothing against it in the guidelines, I just think is adds to > confusion. Then you have python-foo (from rhel), python3-foo (that only > makes the 34 version) and python36-foo (that only makes the python36 > version). If at all possible it would be best to keep the number of packages > down. Additionally, when say there's a python37, the python3 package could > move to that and coonfuse things more. :) Please consider to open a ticket about this issue. The current plan is to have a maximum of two python3 versions in EPEL. The dedicated wiki page is outdated anyways. https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
… Well, and that's another bug in rhbz to forget actual close reason/status.