On 5/28/2015 12:26 PM, Paul Moore wrote:
On 28 May 2015 at 19:22, Chris Angelico <ros...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
