From Fedora Project Wiki

Line 8: Line 8:
  
 
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).
 
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).
 +
 +
{{admon/note|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.
 +
}}

Revision as of 10:57, 17 December 2014

Sharing Packages between Python 3 installations?

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.png
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.