From Fedora Project Wiki

Core concept

Remove the /usr/bin/python symlink from the python2 package and make it:

  1. Uninstalled by default (even if python2 is installed)
  2. 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)