On 31 July 2017 at 05:40, Björn Persson <Bjorn@rombobjörn.se> wrote: > Gerald Henriksen <ghenriks@xxxxxxxxx> wrote: >> On Fri, 28 Jul 2017 21:06:45 +0200, you wrote: >> >Why is not providing /usr/bin/python more use hostile? Why is it better >> >for any script to use /usr/bin/python instead of /usr/bin/python3? >> >> Because any user of Fedora trying to learn Python using either books >> or online sources will be told to type "python" and said user will >> expect it to work. > > Those instructions are indeed part of the problem. Those instructions work everywhere *except* on platforms that are currently reserving "python" to specifically mean Python 2. On Windows? "python" may refer to either Python 2 or 3, whichever you set up via PATH In a Python virtual environment? "python" may refer to either Python 2 or 3, whichever is currently activated Using environment modules, Software Collections, or nix environments? As for Python level virtual environments Using a cross-platform environment manager like conda? As for Python level virtual environments In a shebang line as "/usr/bin/env python"? As for Python level virtual environments System Python installations on Linux and other *nix systems are well and truly the odd ones out at this point (and even there, a number of distros have already decided that having "/usr/bin/python" mean "/usr/bin/python3" is the right choice for their user base). That said, having "python" be absent by default in Fedora Server makes a lot of sense (for simple outright failures when running old unported scripts), as does making it easy to point it at Python 2 (for full backwards compatibility with RHEL 7 and derivatives, and near-full compatibility with the Python 2.6 stack in RHEL 6 and derivatives). Having it be absent by default in Fedora Workstation makes markedly less sense, though, and there it's more desirable to make it point to Python 3 (for the benefit of folks just starting to learn Python, and for developers that prefer to use Py3 ourselves, and only need Python 2.7 for cases where we're working on an existing 2.7 application, or else targeting RHEL or a derivative and can't use Software Collections or container images for some reason). Thus the idea of moving "/usr/bin/python" *out* of the python2 package, and into its own "python2-as-default" package: that allows the decision of "What does '/usr/bin/python/ run?" to be cleanly separated from "Which versions of Python do I have installed?". That particular approach then wouldn't even need to rely on the new modularity system or xdg-alternatives - it could just be a plain old pair of mutually conflicting packages, where "python2-as-default" (built as a subpackage of the python2 SRPM) pointed the symlink at python2 and "python3-as-default" (built as a subpackage of the python3 SRPM) pointed it at python3. Cheers, Nick. P.S. After talking to Petr Viktorin about it off-list, I *don't* think we should do anything similar for the unqualified "python-foo" RPM dependencies - once the Python 2.7 stack goes away, those unqualified provides can disappear along with it. If it turns out that a future Python 4.0 is judged to be a drop-in replacement for the last Python 3.x release, then that will be a nice problem to have, and presumably one we'll have the appropriate tools to handle. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
