From Fedora Project Wiki
| Line 12: | Line 12: | ||
= Design options = | = 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. | 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. | ||
| Line 19: | Line 19: | ||
Pros: | 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: | 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) | 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: | 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: | 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 | 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: | 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: | 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) | |||
Revision as of 14:00, 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
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)