Core concept
By Fedora 28 (it's too late to submit this for F27), remove the /usr/bin/python symlink from the python2 package and make it:
- Uninstalled by default (even if python2 is installed)
- Configurable by admins between python2 and python3
Key assumptions
- User level activation of different Python versions will be handled through existing mechanisms (virtual environments, conda, pyenv, environment modules, Software Collections, etc)
- We'll have a "python2" module that has at least a Python 2.7 stream, and probably a legacy 2.6 stream to enable RHEL/CentOS 6 integration testing (for folks that care about that)
- We'll have a "python3" module that has streams for 3.4, 3.5, and 3.6
- Unlike the "python" hook, we probably *won't* offer free choice of what "python2" and "python3" mean, since those are defined as targets for system packages in the packaging policy
- At a modularity tooling feature level, this suggests a couple of things:
- whether or not streams are parallel installable will likely need to be a module level setting
- we may need a way to modules and/or packages to say "only install this part if this is the default stream for the current platform"
Design options
Alternatives
Since alternatives requires a default, the "uninstalled by default" behaviour would be implemented as a high priority "no-default-python" option that didn't actually run python scripts, but instead printed out a custom error message explaining that there's no default python selected, and indicating which alternatives are available.
python2 and python3 would be updated to register themselves as available alternatives for /usr/bin/python (with dependent groups for other commands like /usr/bin/pip)
Pros:
- extends nicely to other Python runtimes (e.g. PyPy)
- aligns with one of the possibilities that Debian's Matthias Klose mentioned at the Python Language Summit a couple of years ago https://lwn.net/Articles/640296/
Cons:
- not clear how it would apply to Atomic Host due to assumption of stateful system management
- requires FPC approval, since Py3 is not a drop-in replacement for Py2
Mutually conflicting RPMS
Allows /usr/bin/python to be truly missing by default, but it isn't clear that's a good thing (since the default error message from the shebang handler when it can't find a scripting engine is fairly uninformative)
Pros:
- no configuration state involved other then the list of installed RPMs
- may make sense as the non-modular result of converting the modular solution back to a monolithic repo
Cons:
- doesn't extend to other Python runtimes beyond the default pair
- still not clear how it would apply to Atomic Host due to assumption of post-system-install RPM installation
- requires FPC approval, since this isn't a pre-approved use of Conflicts
default-python module with 2.x and 3.x streams
Rather than using any mechanism that assumes management of a persistent mutable system, instead rely on the new module system to select the target of /usr/bin/python by defining a new "default-python" package and module, with 2.x and 3.x streams that set the symlink appropriately.
Pros:
- aligns with the general future direction of Fedora's management of this kind of problem
- aligns with the tooling for composing custom Atomic base images (just choose the desired default-python stream as a component to include)
Cons:
- potentially only applies to the new Fedora Modular Server, and not the traditional all-in-one monolithic repo configuration (however, that would depend on how the default-python streams get mapped to the monolithic repo - they *could* be designed so as to produce the mutually-conflicting RPMs case described above)