On Fri, May 29, 2015 at 3:20 AM, Donald Stufft <donald@stufft.io> wrote:
On May 28, 2015 at 12:54:34 PM, Chris Angelico (rosuav@gmail.com) wrote:
Is this a Windows-specific issue, or is it also intended for Linux and Mac OS, where there'll already be a system Python (so a single-file-executable would be used to be independent of the system Python)?
I think it’s an issue for all platforms, even when there is a system Python that can be used.
Here’s why:
* Even on Linux systems Python isn’t always a guaranteed thing to be installed, for instance Debian works just fine without any Python installed.
* On OS X you have the system Python yes, but that is in an unknown state. It could have any number of changes made to it or things installed or what have you.
* Even if you have Python installed already, is it the right one? What if it’s an ancient RHEL box that has 2.6 or (heaven forbid) 2.4? What if it’s a not ancient box that has Python 2.7 but you want to deploy your app in Python 3?
* What if you have Python installed already, but it’s been patched by the place you got it from and now the behavior is different than what you expected?
The independence argument. Yep, reasonable. The trouble is that if everyone seeks to be independent of the system Python, it makes the system Python redundant with every single Python app; and the bundled Python will have to be platform-specific (not just OS, but architecture, word size, possibly OS version in some cases, etc, etc). And that independence also means you miss out on security/compatibility updates from upstream, so you're having to manage your own updates. I'd still much rather see a small stub that goes and calls on a system Python than something that has to duplicate all of Python into every binary, but it's a choice for the application developer to make. If there can at least be an easy way to strip off the self-executability header and get back the base Python application, that would be a big help - you could have a script that goes through all your executables, looks for the signature that says "hi, I'm a Python 2.7.10 self-runner", and strips it off in favour of a 2.7.11 that fixes some critical issue. Or you could strip that off and run the underlying Python code on a different OS. Binary blobs are so often unworkable. ChrisA