Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems
On Wed, Feb 13, 2019 at 10:26 AM Petr Viktorin wrote: > PEP 394 says: > > > This recommendation will be periodically reviewed over the next few > > years, and updated when the core development team judges it > > appropriate. As a point of reference, regular maintenance releases > > for the Python 2.7 series will continue until at least 2020. > > I think it's time for another review. > I'm especially worried about the implication of these: > > - If the `python` command is installed, it should invoke the same >version of Python as the `python2` command > - scripts that are deliberately written to be source compatible >with both Python 2.x and 3.x [...] may continue to use `python` on >their shebang line. > > So, to support scripts that adhere to the recommendation, Python 2 > needs to be installed :( > I literally just ran into this problem now. Part of a software suite I've written uses Python to fetch updates during the installation process. Due to the target audience, it needs to access the system Python (only), and support systems as old as RHEL 5 (Python 2.4 and later, including Python 3.x in the same code base, using nothing but the stdlib). The shebang line was "#!/usr/bin/env python" It's been working for years, but was only now reported broken by a user that upgraded their Ubuntu distribution and suddenly had no "python" executable anywhere. But they had python3. I suspect suddenly not having any "python" executable in a Linux system will screw up a lot more people than just me. The workaround was ugly. I'd like to see there always be a `python` executable available if any version of Python is installed. Thanks, Jason -- Jason M. Swails ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems
> On Feb 14, 2019, at 3:44 AM, Antoine Pitrou wrote: > > On Thu, 14 Feb 2019 00:57:36 -0500 > Jason Swails wrote: >> >> I literally just ran into this problem now. Part of a software suite I've >> written uses Python to fetch updates during the installation process. Due >> to the target audience, it needs to access the system Python (only), and >> support systems as old as RHEL 5 (Python 2.4 and later, including Python >> 3.x in the same code base, using nothing but the stdlib). The shebang line >> was "#!/usr/bin/env python" >> >> It's been working for years, but was only now reported broken by a user >> that upgraded their Ubuntu distribution and suddenly had no "python" >> executable anywhere. But they had python3. >> >> I suspect suddenly not having any "python" executable in a Linux system >> will screw up a lot more people than just me. The workaround was ugly. > > I'm not sure what you mean. Isn't the workaround to install Python 2 > in this case? I release the software, so the problem is not my machine, it’s others’. The installation process also fetches a local miniconda distribution for the Python utilities that are part of the program suite (and the python programs are optional and typically not installed when this suite is deployed on a supercomputer, for instance). But the software needs to check for updates before it does any of that (hence my concern — this script needs to be able to run before the user does *anything* else, including installing dependencies). This would also be the first time we’d have to give different installation instructions for different versions of the same Linux distro. The workaround from a users perspective is simple for me, but I can’t make that same assumption for all of my users. This is an impediment to keeping the user experience as simple as possible. Thanks, Jason ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
