Being able to provide multiple python interpreters in parallel presents some useful opportunities and some "interesting" challenges.
Being able to install multiple python interpreters next to each other gives us the option to not have to hold back python upgrades until all python packages have been confirmed/patched to be working with the new version.
This also means that it will be easy for users of -git source-only packages to install and play with pre-release/beta python interpreters without having to be afraid to inadvertently ruin their existing python installs.
- A suitable mechanism (virtual providers) is devised by which the user can indicate which python version the package atom
virtual(python3) refers to. This will need to have a default value at install time.
- A suitable mechanism (virtual provider or symlink sub-package) is devised by which the user can control which python version the default
python file system symlink points to.
IFF the above is implemented, THEN it will be possible to specify in a given recipe whether it is compatible with any python3 or has only been shown to work with a single python3.X. This means that if we have, say, 100 python3 recipes in our recipe repositories, they can each be held back by simply switching from the generic virtual(python3) provider to the specific binary(python3.x) provider in their builddeps section.
To make this work, we could add a python analyser that checks for .py files that contain
#!/.../python shebang lines and actively rewrites them to match the default official Serpent OS upstream virtual provider at build-time XOR a custom specified binary provider at build time. The custom binary provider choice would mainly be useful for testing packages against non-default python versions (brand new or, alternatively, older releases).
In addition, we could ensure that each package is explicitly installed to the versioned
/usr/lib/python3.X/site-packages/ (and automatically rundep on the corresponding
binary(python3.X)), though this implies that we need to do mass python rebuilds whenever the default official Serpent OS upstream provider changes. It must be noted, however, that this would need to happen regardless. With this approach, we can move recipes over gradually and in multiple commits, as the non-updated recipes would continue to be installed to the earlier
/usr/lib/python3.X/site-packages/ dir and/or use the earlier shebang version.
The good news is that re-installing the new packages will automagically happen on updates, because we intend to resolve the "installed set system model" on each update transaction. So the installed packages will stay installed but have their rundeps updated appropriately.
As a corollary, this also means that the default
python symlink need not be the same as the
virtual(python3) atom, but in the default case it likely will be. This particular way of going about solving the problem has the additional benefit of being able to support e.g. a hypothetical (source-only!) python-2.7 version used with legacy in-house solutions without affecting the default python-3.x virtual provider (as all packages will have their shebangs re-written to the provider specified in their builddeps).
Finally, this approach also allows us to easily migrate to a hypothetical future python4 virtual provider by simply using the existing upgrade approach of pinning python4-incompatible packages to the latest python3.x version and switching the rest to use the virtual(python4) provider.