Description of problem: Default Fedora 27 Base Cloud image has python3 installed but there is no "python" executable in PATH. Installing default OS python should add "python" executable to the path (as a symlink to python3 one). How reproducible: Always. Boot, type "python". Additional info: This will break almost all possible python tools, even if they support python3. For example Ansible fails to connect to fc28 machines because it fails to find /usr/bin/python executable. The default behavior should be to have the unversioned executable in PATH.
I agree with you. However, Fedora follows upstream in this issue; specifically [PEP 394] which explicitly says: > for the time being, all distributions should ensure that python, if installed, refers to the same target as python2, unless the user deliberately overrides this or a virtual environment is active. https://www.python.org/dev/peps/pep-0394/ If you want to change PEP 394, please take the discussion upstream. Check Ansible documentation on setting the Python interpreter.
I read PEP-0394 entirely and I do not think that not creating a 'python' symlink is ever stipulated in it. Also keep in mind that this pep is about 7 years old and even the paragraph that you mentioned started with "for the time being,...". Combine with its age, I would say that that time passed and we need to focus on providing a good user experience. If we ship only one interpreter by default (python3), I do not see any reasons for not creating that magic symlink that could save an endless number of hours for everyone writing python scripts. Arch Linux did that a long time ago and I am sure others will quickly follow. Meanwhile, I will also take the discussion upstream and try to update the famous PEP 394 to clarify the recomandation, which obviosuly missed the cover the case where only python3 is installed.
> I read PEP-0394 entirely and I do not think that not creating a 'python' symlink is ever stipulated in it. The PEP says "If the python command is installed, it should invoke the same version of Python as the python2 command." If python2 is not there, there's no way for a `python` command can't do that. > Also keep in mind that this pep is about 7 years old and even the paragraph that you mentioned started with "for the time being,...". Combine with its age, I would say that that time passed and we need to focus on providing a good user experience. The "Created" date doesn't matter. It's a living document, and was updated quite recently. > If we ship only one interpreter by default (python3), I do not see any reasons for not creating that magic symlink that could save an endless number of hours for everyone writing python scripts. > > Arch Linux did that a long time ago and I am sure others will quickly follow. > > Meanwhile, I will also take the discussion upstream and try to update the famous PEP 394 to clarify the recomandation, which obviosuly missed the cover the case where only python3 is installed. When you do, consider past discussions, especially this one I started in April (and which ended in compromise): https://github.com/python/peps/pull/630
I created https://github.com/python/peps/pull/785 and I am still reading the one from April. Apparently Guido does not like the idea which makes me think that my chances of getting it in will soon hit the floor, even if there were some changes since April ;) I care a lot about UX, and I find the missing interpreter errors as a real source of alienation for the users. I also created a ticked on Ansible as this seems to be seriously affected by this issue https://github.com/ansible/ansible/issues/45852 -- especially as it concerns running code on remote hosts which may have one version or another.
This issue also affects me. For a first-timer, the user experience of using Ansible with Fedora cloud images is bumpy. It looks like Ansible 2.8 may have a work-around (from Sorin's RFE), but it would be nice to see some other solution make it down the pipe faster (even if only specific to the Fedora cloud images).
Looking at the PEP again and I see the following interesting points: > for the time being, all distributions should ensure that python, if installed, refers to the same target as python2 we do that > unless the user deliberately overrides this we provide no supported and documented way to do so Likewise: > The Python 2.x idle, pydoc, and python-config commands should likewise be available as idle2, pydoc2, and python2-config, with the original commands invoking these versions by default we do that > but possibly invoking the Python 3.x versions instead if configured to do so by the system administrator. we provide no supported and documented way to do so See also https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_3:_Switch_python_to_refer_to_python3 > Make python mean Python 3 in Fedora. This would mean ... invoking python ... will run a Python 3 version of the interpreter. we cannot do that (yet) because... > The steps needed to achieve this will be done in combination with proposing changes to the upstream guidance in PEP 394. However... > Note that after Phase 1, nothing in Fedora uses /usr/bin/python any more, so it should be safe for sysadmins to flip the symblink back to python2 and we should provide a documented and supported way of doing so. I see no blocker for doing this the other way around: After Phase 1, nothing in Fedora uses /usr/bin/python any more, so it should be safe for ̶s̶y̶s̶a̶d̶m̶i̶n̶s̶ **users** to flip the symblink to python3 or back and we should provide a documented and supported way of doing so. ------- One way of doing this might be https://fedoraproject.org/wiki/Alternatives_system however https://fedoraproject.org/wiki/Packaging:Alternatives says: > (use when) the software can be used as a drop-in replacement and functions with sufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed This is unfortunately not true for Pythons. > (use when) the selection of the software is only performed system-wide by the system administrator and end users do not have a need to switch between the variants. This is unfortunately not true for Pythons either. Also: > (not use when) The software is not a drop-in replacement. For instance, if common command line arguments are different between the two variants, alternatives MUST NOT be used. ------- Another possible solution would be to have python3-unversioned-command and python2-unversioned-command packages and make them conflict. Make python2 recommend python2-unversioned-command and make python3 suggest python3-unversioned-command. That should follow the PEP as long as we consider people who use dnf/rpm "users" and not "sysadmins". ------- Another possible solution is to keep the packages as they are and only provide a documented, easy and safe way to do so as an user (not sysadmin). Together with https://fedoraproject.org/wiki/Changes/UserPathPrioritization this might simply be: $ mkdir -p ~/.local/bin && ln -s /usr/bin/python3 ~/.local/bin/python $ python --version Python 3.7.0 This would follow the PEP to the letter, as it's obviously an user's deliberate action and not sysadmins (in fact I have just done that as an user and I didn't even need root). It would not solve the Ansible issue if Ansible looks into /usr/bin/pytohn explicitly and/or if this needs to be done before we can manage the machine by Ansible (so we cannot do it by Ansible). ------- Not sure if a CLOSED bug is a right place to discuss this, however it just crossed my mind as I was reading https://github.com/python/peps/pull/630
(In reply to Miro Hrončok from comment #6) > Looking at the PEP again and I see the following interesting points: > > > for the time being, all distributions should ensure that python, if installed, refers to the same target as python2 > > we do that > > > unless the user deliberately overrides this > > we provide no supported and documented way to do so We do: venv/virtualenv is fully supported. https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html > Likewise: > > > The Python 2.x idle, pydoc, and python-config commands should likewise be available as idle2, pydoc2, and python2-config, with the original commands invoking these versions by default > > we do that > > > but possibly invoking the Python 3.x versions instead if configured to do so by the system administrator. > > we provide no supported and documented way to do so True. But that sounds secondary to `python` being switchable. Not really worth the effort, IMO. > ------- > > Another possible solution would be to have python3-unversioned-command and > python2-unversioned-command packages and make them conflict. Make python2 > recommend python2-unversioned-command and make python3 suggest > python3-unversioned-command. That should follow the PEP as long as we > consider people who use dnf/rpm "users" and not "sysadmins". They are definitely sysadmins :( > ------- > > > Another possible solution is to keep the packages as they are and only > provide a documented, easy and safe way to do so as an user (not sysadmin). > Together with https://fedoraproject.org/wiki/Changes/UserPathPrioritization > this might simply be: > > $ mkdir -p ~/.local/bin && ln -s /usr/bin/python3 ~/.local/bin/python > $ python --version > Python 3.7.0 > > This would follow the PEP to the letter, as it's obviously an user's > deliberate action and not sysadmins (in fact I have just done that as an > user and I didn't even need root). It would not solve the Ansible issue if > Ansible looks into /usr/bin/pytohn explicitly and/or if this needs to be > done before we can manage the machine by Ansible (so we cannot do it by > Ansible). So, we should just document that?
> So, we should just document that? I think so.