[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)
v+python at g.nevcal.com
Thu May 28 23:09:24 CEST 2015
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...
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
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
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...
More information about the Python-Dev