User talk:Bkabrda/EPEL7 Python3

Sharing Packages between Python 3 installations?

• Python 3 offers a stable ABI option: https://www.python.org/dev/peps/pep-0384/

• It also uses a pyc caching format that allows the same source files to be shared by multiple interpreters without conflict: https://www.python.org/dev/peps/pep-3147/

We should consider whether we want to allow the parallel Python 3 installations to share packages in some manner, such that we don't have to build multiple copies of packages (whether pure Python or with C extensions using the stable ABI) that could actually happily run across all supported Python versions.

For example, if a package supports Python 3.3+, it could be eligible for installation in a shared location that we ensured was added to the default sys.path for all Python 3 versions built for EPEL (after the regular 3.x specific directories).

Note from bkabrda
This sounds nice, several notes/concerns/comments:

• What of the packages that use something beyond stable ABI? These'll have to be named pythonXY-foo, right? In case we'll have some packages python34-foo and others python3-bar, things might get a bit confusing. Same applies to potential pure Python packages working just with python3X, but not with 3X+1 (or 3X-1).
• In the situation when there are python3X and python3X+1 in EPEL together, package will need to BR both to generate both bytecodes properly - and we'll need to create RPM hooks to generate both bytecodes in the shared directory. Also, these packages should *Require* both, since they'll ship both bytecodes in a single package (or we'd need to create subpackages for bytecodes, which would be both ugly and unusable).
• When a new python3X+1 is introduced, extension packages will need hand adjustment, but probably a bit less than the original proposal (when building package for both python3X and 3X+1, we should do %build, %install and %check for both runtimes anyway, the only work saved would be not introducing subpackages; but if we don't introduce any subpackages, we'll end up with packages requiring two runtimes, which is ugly).
• python3-bar that depends on python3-foo has no way of knowing whether python3-foo has already been built and tested with python3X+1.

All in all, I'd prefer to go with "explicit rather than implicit" in this case - both to keep all package names consistent and to make sure we know what has been built with which runtime and what precisely will get installed in minimal buildroots/on user machines.