(Created page with "= 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 ...") |
|||
| Line 3: | Line 3: | ||
Remove the /usr/bin/python symlink from the python2 package and make it: | 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 assumption = | = Key assumption = | ||
Revision as of 13:57, 31 July 2017
Core concept
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 assumption
User level activation of different Python versions will be handled through existing mechanisms (virtual environments, conda, pyenv, environment modules, Software Collections, etc)
Design options
1. Alternatives (requires FPC approval, since Py3 is not a drop-in replacement for Py2)
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
2. Mutually conflicting RPMS (requires FPC approval, since this isn't a pre-approved use of Conflicts)
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
3. default-python module with 2.x and 3.x streams
Rather than using any existing mechanism, 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)