<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><span style="font-size: 13pt;"> </span><br><div dir="ltr"><br>On Feb 14, 2019, at 3:44 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>On Thu, 14 Feb 2019 00:57:36 -0500</span><br><span>Jason Swails <<a href="mailto:jason.swails@gmail.com">jason.swails@gmail.com</a>> wrote:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I literally just ran into this problem now. Part of a software suite I've</span><br></blockquote><blockquote type="cite"><span>written uses Python to fetch updates during the installation process. Due</span><br></blockquote><blockquote type="cite"><span>to the target audience, it needs to access the system Python (only), and</span><br></blockquote><blockquote type="cite"><span>support systems as old as RHEL 5 (Python 2.4 and later, including Python</span><br></blockquote><blockquote type="cite"><span>3.x in the same code base, using nothing but the stdlib). The shebang line</span><br></blockquote><blockquote type="cite"><span>was "#!/usr/bin/env python"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It's been working for years, but was only now reported broken by a user</span><br></blockquote><blockquote type="cite"><span>that upgraded their Ubuntu distribution and suddenly had no "python"</span><br></blockquote><blockquote type="cite"><span>executable anywhere. But they had python3.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I suspect suddenly not having any "python" executable in a Linux system</span><br></blockquote><blockquote type="cite"><span>will screw up a lot more people than just me. The workaround was ugly.</span><br></blockquote><span></span><br><span>I'm not sure what you mean. Isn't the workaround to install Python 2</span><br><span>in this case?</span><br></div></blockquote><div><br></div>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). <div><br></div><div>This would also be the first time we’d have to give different installation instructions for different versions of the same Linux distro. </div><div><br></div><div>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. </div><div><br></div><div>Thanks,</div><div>Jason</div><div><div><blockquote type="cite"><div dir="ltr"><span></span></div></blockquote></div></div></body></html>