[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Glenn Linderman]

On 5/28/2015 12:26 PM, Paul Moore wrote:
> On 28 May 2015 at 19:22, Chris Angelico <rosuav at gmail.com> wrote:
>>> Unfortunately (and believe me, I've been down this road many times) on
>>> Windows *only* the exe format is a "first-class" executable.
>>> Executable scripts and shebangs are very useful, but there are always
>>> corner cases where they don't work *quite* like an exe. On Windows,
>>> you have to be prepared to ship an exe if you want to compete with
>>> languages that generate exes.
>> I'm aware of that. When I said "a tiny stub", I was thinking in terms
>> of a small executable. The idea is that its sole purpose is to locate
>> Python someplace else, and chain to it; that has to be actual
>> executable code, complete with the 512-byte "MZ" header and
>> everything, to ensure compatibility. But it should be able to be
>> small, tight, and easy to verify correctness of, so there aren't (in
>> theory!) security exploits in the header itself.
> OK, cool. I'm sort of working on that as a bit of a side project - a
> tiny stub exe that you can prepend to a Python zipapp which runs it
> via the standard embedding APIs. It's little more than an idea at the
> moment, but I don't think it'll be too hard to implement...

Paul,

I've been using zipapps for some years now, and it would be really cool 
to have what I think you are talking about here:

1) Build zipapp as normal.  It likely depends on some minimal Python 
version.
2) Prepend stub .exe (Windows) or !# line (Unix) that declares a version 
of Python to actually use. This can be as broad as Python 2 or Python 3 
(not sure how to specify that either works, especially on Windows), or 
more detailed/restrictive by specifying  2.n or 3.n.  On Windows, it 
would find the newest qualifying installation and run it, and Unix, the 
symlinks are set up to do that already, is my understanding, so the 
proper !# line does that for you.

This would be something I could use and benefit from immediately upon it 
being available, so I laud your idea, and hope you have a successful 
implementation, and look forward to using it.  It would largely replace 
the need for the py.exe launcher for some classes of applications.

Of course, per other disccusions, this doesn't solve the problem for:

A) machine without Python installed
B) programs that need binary extensions

Other discussions have suggested:

3) The stub could offer to download and install Python

A corollary:

4) The stub could offer to download and install the needed binary 
extensions as well as Python. This would require the installation 
uniformity of something like pip, so perhaps would be restricted to 
extensions available via pip.  And it would be much enhanced by some 
technique where the zipapp would contain metadata readable by the stub, 
that would declare the list of binary extensions required. Or, of 
course, it could even declare non-binary extension that are not packaged 
with the zipapp, if the process is smooth, the modules available via 
pip, etc., as a tradeoff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150528/dba720a2/attachment.html>