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