[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Brett Cannon]

On Thu, May 28, 2015 at 3:25 PM Chris Barker <chris.barker at noaa.gov> wrote:

> OK, I'm really confused here:
>
> 1) what the heck is so special about go all of a sudden? People have been
> writing and deploying single file executables built with C and ++, and
> whatever else? forever. (and indeed, it was a big sticking point for me
> when I introduced python in my organization)
>

Because Go is much easier to use to write those CLI apps than C or C++. The
barrier now is low enough that the ease of development plus the ability to
do statically compiled binaries is enticing folks to drop Python and Ruby
for Go when making a CLI app.


>
> 2) Why the sudden interest in this as core a Python issue? I've been using
> Python for desktop apps, on primarily Windows and the Mac for years -- and
> had to deal with py2exe, py2app, etc. forever. And it has been a very very
> common question on the various mailing lists for ages: how do I deploy
> this? how do I make it easy to install? The answer from the developers of
> cPython itself has always been that that's a third party problem -- and go
> look for py2exe and friends to solve it. And that it is a solved-enough
> problem. The biggest "unsolved" issues are that you get a really  big
> application.
>

Anecdotal evidence suggests Go's user base has a decent amount of converts
from Python and it's currently the only language that seems to be siphoning
people out of our community. You do hear stories of people skipping Python
3 and going to Go, but considering how much more work that is than writing
Python 2/3 code I believe that typically happens when the organization
wanted to jump ship anyway and the Python 3 transition just gave them an
excuse to rewrite their stuff (plus we all know how enticing it can be to
play with a shiny new piece of tech if given the chance).


>
> Don't get me wrong -- I've wanted for years for it to be easier to deploy
> python-based apps as a single thinking for users to easily install and
> uninstall where they don't need to know it's python -- but what the heck is
> different now?
>

Active user loss where the biggest reason people are leaving that we can
actively fix now is easy app deployment (the other is performance; some
might argue concurrency but concurrent.futures and async/await water that
down somewhat for me).


>
> 3) There was mention of a platform-neutral way to do this. Isn't that
> simply impossible? The platforms are different in all the ways that matter
> for this problem: both technical differences, and conventions. Which isn't
> to say you couldn't have one API to produce a single "thing" executable, so
> it would look like one solution for multiple platforms to the user. But the
> end product should be (would have to be) a different beast altogether.
>

I think it's to have a single tool to do it for any platform, not to have
the technical nuts and bolts be the same necessarily. I think it's also to
figure out if there is anything the interpreter and/or stdlib can do to
facilitate this.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150528/581c0f25/attachment-0001.html>