From Fedora Project Wiki
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:
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.
Note from ncoghlan
Yeah, I think you're right. While it would be nice to find a way to take advantage of the stable ABI, it makes sense to stick with the simpler approach since we already have the necessary build infrastructure to handle full parallel stacks.
Yeah, I think you're right. While it would be nice to find a way to take advantage of the stable ABI, it makes sense to stick with the simpler approach since we already have the necessary build infrastructure to handle full parallel stacks.