<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 11:38 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 28 May 2015 at 16:58, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> On May 28, 2015, at 11:39 AM, Donald Stufft wrote:<br>
><br>
>>You don’t need a "fully functioning Python" for a single file binary, you<br>
>>only need enough to actually run your application. For example, if you're<br>
>>making an application that can download files over HTTP, you don't need to<br>
>>include parts of the stdlib like xmlrpc, pickle, shelve, marshall, sqlite,<br>
>>csv, email, mailcap, mailbox, imaplib, nntplib, etc.<br>
><br>
> There are actually two related but different use cases to "single file<br>
> executables".<br>
><br>
> The first is nicely solved by tools like pex, where you don't need to include<br>
> a fully functional Python at the head of the zip file because the environment<br>
> you're deploying it into will have enough Python to make the zip work.  This<br>
> can certainly result in smaller zip files.  This is the approach I took with<br>
> Snappy Ubuntu Core support for Python 3, based on the current situation that<br>
> the atomic upgrade client is written in Python 3.  If that changes and Python<br>
> 3 is removed from the image, then this approach won't work.<br>
><br>
> pex (and others) does a great job at this, so unless there are things better<br>
> refactored into upstream Python, I don't think we need to do much here.<br>
<br>
</span>One problem with pex is that it doesn't appear to work on Windows (I<br>
just gave it a try, and got errors because it relies on symlinks).<br>
<br>
IMO, any solution to "distributing Python applications" that is<br>
intended to compete with the idea that "go produces nice single-file<br>
executables" needs to be cross-platform. At the moment, zipapp (and in<br>
general, the core support for running applications from a zip file)<br>
handles this for the case where you're allowed to assume an already<br>
installed Python interpreter. The proviso here, as Donald pointed out,<br>
is that it doesn't handle C extensions.<br>
<br>
The biggest problem with 3rd-party solutions is that they don't always<br>
support the full range of platforms that Python supports. That's fine<br>
for a 3rd party tool, but if we want to have a response to people<br>
asking how to bundle their application written in Python, we need a<br>
better answer than "if you're on Windows, use py2exe, or if you're on<br>
Unix use pex, or maybe..."<br>
<br>
Python has core support for the equivalent of Java's jar format in<br>
zipapp. It's not well promoted (and doesn't support C extensions) but<br>
it's a pretty viable option for a lot of situations.<br>
<span class=""><br>
> The second use case is as you describe: put a complete functional Python<br>
> environment at the head of the zip file so you don't need anything in the<br>
> target deployment environment.  "Complete" can easily mean the entire stdlib,<br>
> and although that would usually be more bloated than you normally need, hey,<br>
> it's just some extra unused bits so who cares? <wink>.  I think this would be<br>
> an excellent starting point which can be optimized to trim unnecessary bits<br>
> later, maybe by third party tools.<br>
<br>
</span>Tools like py2exe and cx_Freeze do this, and are pretty commonly used<br>
on Windows. An obvious example of use is Mercurial. If you're looking<br>
at this scenario, a good place to start would probably be<br>
understanding why cx_Freeze isn't more commonly used on Unix (AFAIK,<br>
it supports Unix, but I've only ever really heard of it being used on<br>
Windows).<br></blockquote><div><br></div><div>Esky <a href="https://github.com/cloudmatrix/esky/">https://github.com/cloudmatrix/esky/</a> </div><div><br></div>* supports "py2exe, py2app, cxfreeze and bbfreeze"<br>* builds a zip archive containing an .exe<br>* manages (failed) [auto-]updates</div><div class="gmail_quote"><br></div><div class="gmail_quote">PEX <a href="https://pantsbuild.github.io/pex_design.html">https://pantsbuild.github.io/pex_design.html</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">* adds an executable header to a (topo-sorted?) ZIP file with a minimal path</div><div class="gmail_quote"><br></div><div class="gmail_quote">* pipsi <a href="https://github.com/mitsuhiko/pipsi/blob/master/pipsi.py">https://github.com/mitsuhiko/pipsi/blob/master/pipsi.py</a></div><div class="gmail_quote">  * installs packages with console_scripts into separate virtualenvs with minimal sys.paths and ~/.local/bin)</div><div class="gmail_quote"><br></div><div class="gmail_quote">At the end of the day I still need packaging or configmgmt or NIX</div><div class="gmail_quote">for checksums (a manifest wrapped around the executable wrapper).<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I suspect "single file executables" just aren't viewed as a desirable<br>
solution on Unix. Although Donald referred to a 4K binary, which<br>
probably means just a stub exe that depends on system-installed .so<br>
files, likely including Python (I'm just guessing here). It's easy to<br>
do something similar on Windows, but it's *not* what most Windows<br>
users think of when you say a "single file executable for a Python<br>
program" (because there's no system package manager doing dependencies<br>
for you).<br></blockquote><div><br></div><div>NuGet, Chocolatey, -> OneGet</div><div><br></div><div>It's a topologically sorted adjacency list + build + install + uninstall scripts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Again, platform-specific answers are one thing, and are relatively<br>
common, but having a good cross-platform answer at the language level<br>
(a section on <a href="http://docs.python.org" target="_blank">docs.python.org</a> "How to ship your Python program") is<br>
much harder.<br>
<span class=""><br>
>>Of course deciding which pieces you include in the zip file you're appending<br>
>>to the end of Python is up to whatever tool builds this executable which<br>
>>doesn't need to be part of Python itself. If Python itself gained the ability<br>
>>to operate in that manner than third party tools could handle trying to do<br>
>>the optimizations where it only includes the things it actually needs in the<br>
>>stdlib and excludes things it doesn't. The key thing here is that since<br>
>>you're doing a single file binary, you don't need to have a Python which is<br>
>>suitable to execute random Python code, you only need one that is suitable to<br>
>>execute this particular code so you can specialize what that includes.<br>
><br>
> I'd love to see Python itself gain such a tool, but if it had the critical<br>
> pieces to execute in this way, that would enable a common approach to<br>
> supporting this in third party tools, on a variety of platforms.<br>
<br>
</span>Stripping out unused code is a hard problem in a language as dynamic<br>
as Python. It would be great to see it happen, but I'm not sure how<br>
much better we can do than existing tools like modulefinder. (consider<br>
that stripping out parts of the stdlib is the same in principle as<br>
stripping out unused bits of a 3rd party library like requests - when<br>
this issue comes up, people often talk about slimming down the stdlib<br>
to just what's needed, but why not take out the json support from<br>
requests if you don't use it?)<br></blockquote><div><br></div><div>Is this what they do for AppEngine / AppScale Python?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> I do think single-file executables are an important piece to Python's<br>
> long-term competitiveness.<br>
<br>
</span>Agreed. But also, I think that "single-file" executables<br>
(single-directory, in practice) are *already* important - as I say,<br>
for projects like Mercurial. Doing better is great, but we could do<br>
worse than start by asking the Mercurial/TortoiseHg project and others<br>
what are the problems with the current situation that changes to the<br>
core could help to improve. I doubt "please make pythonXY.zip 50%<br>
smaller" would be the key issue :-)<br></blockquote><div><br></div><div>"Select your platform" (According to User-Agent)</div><div><br></div></div></div></div>