On 5/28/2015 12:26 PM, Paul Moore wrote:
On 28 May 2015 at 19:22, Chris Angelico <rosuav@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...


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.