[EPEL-devel] Missing Python 3 bindings for C libraries in EL7
Hi everyone,
Background:
The Pulp 3 upstream project is written in Python 3.
Our installer normally uses PyPI for pure python packages, and OS
packages for C libraries & their python bindings.
Problem:
With RHEL7/CentOS7, we often run into the following thorny situation:
- Package libjuicy, written in C, exists in EL7 (main, optional, or extras).
- Subpackage python2-libjuicy with python2 bindings exists in EL7.
- Subpackage python3-libjuicy does not exist at all for EL7.
Note: libjuicy is a made up name :)
I am not sure how to provide the python3 bindings .
Solutions I've thought of:
1. I see that for pure python packages ("chardet" being an example I
stumbled upon), there's often a python2 package in EL7, but a python3
package in EPEL7. Often at different versions. And I found guidelines
for this. [1]
However, I am worried about robustness (& feasibility) of a
python3-libjuicy bindings-only source package in EPEL7 for an EL7
libjuicy. What if there's a libjuicy update and it breaks the bindings
until we (Pulp / Fedora contributors) update them? And would it be
permissible in EPEL 7?
2. Rebuild the entire EL7 SRPM with changes so it includes the python3
subpackage, and host it on Copr. Example: [2]
However, some of our users, and therefore my teammates, do not want to
add any repo other than EPEL and optional/extras. They would rather
this be in EPEL 7 (or perhaps CentOS 7) somehow.
3. We can request that RHEL7 provides an updated libjuicy with the
python3-libjuicy subpackage.
However, even if they say yes, it would take too long for upstream
release schedule.
Suggestions?
BTW, thank you for all the hard work on EPEL7 Python 3 support. I've
been following the RHEL 7.7 situation.
-Mike
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
[2] proof-of-concept:
https://github.com/mikedep333/libcomps-rpm/commit/f162e237635e90d090e2f2f...