<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<div class="moz-cite-prefix">On 5/28/2015 12:26 PM, Paul Moore
wrote:<br>
</div>
<blockquote
cite="mid:CACac1F9ZyY_1xSk9daK4-Hzqa4pBWa8_N_zTW3aMckVJLT9Rew@mail.gmail.com"
type="cite">
<pre wrap="">On 28 May 2015 at 19:22, Chris Angelico <a class="moz-txt-link-rfc2396E" href="mailto:rosuav@gmail.com"><rosuav@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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...
</pre>
</blockquote>
<br>
Paul,<br>
<br>
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:<br>
<br>
1) Build zipapp as normal. It likely depends on some minimal Python
version.<br>
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.<br>
<br>
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. <br>
<br>
Of course, per other disccusions, this doesn't solve the problem
for:<br>
<br>
A) machine without Python installed<br>
B) programs that need binary extensions<br>
<br>
Other discussions have suggested:<br>
<br>
3) The stub could offer to download and install Python<br>
<br>
A corollary:<br>
<br>
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.<br>
</body>
</html>