[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)
Chris Angelico
rosuav at gmail.com
Thu May 28 19:43:00 CEST 2015
On Fri, May 29, 2015 at 3:20 AM, Donald Stufft <donald at stufft.io> wrote:
> On May 28, 2015 at 12:54:34 PM, Chris Angelico (rosuav at 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
More information about the Python-Dev
mailing list