Hacker News Reader

Comment by nine_k | Hacker News Reader

Go also carries all its dependencies with it; this is why it produces large single static binaries.

Python lacks a tool to painlessly produce the same, that is, a self-contained binary that includes the VM and all the dependencies. Determining Python dependencies may be slightly tricky, because `import` is an executable statement, and dependencies may be native-code libraries.

There are several tools for that, but all have their downsides, and none is in widespread use. Polishing such a tool until it's as simple and fool-proof as Go's build tool could be quite beneficial for Python community.

View on HN

Everyone seem to agree the generation of a static binary is easy with go. That's not my experience as soon as CGO and the glib is involved. I would gladly pay 100$ to make it work on my open source project using libvips to anyone who can create the static build: https://github.com/mickael-kerjean/nuage

Why does it have to be a self-contained binary? When you pack everything into an virtualenv you get more or less the same result, don't you? If you want to have a single file you can zip it :)

Usability-wise, there's a huge gap between even low-effort and no-effort actions.

Another upside of a single binary is that it's not easy to modify; you can even sign it. Quite an upside if you want to audit what you deploy to your production that handles millions of dollars.

Can't you tar the python venv and sign it as well? Might be more difficult to get reproducible builds tgisbway, but it's sort of the same thing isn't it?

You can deploy an executable on a server just by typing

    GOOS=linux GOARCH=386 go build foo && scp foo user@server:

That's a lot of time saved, especially when you do it on a daily basis, and not something you can do as easily with virtualenv and such.

Yea I just do not buy it. How much time is saved? Is it writing an additional SSH command to extract the file or hitting the up-arrow on your keyboard to repeat the previously run command?

Not a lot, but when your test environment is on a remote server (because it replicates the production DB and you can't have that on your dev machine for security reasons), you tend to do it a lot. Add fast compilation to the mix, and you have a very productive workflow. `make && zip && scp && ssh unzip` is way slower than `go build && scp`

There's also xar[1] (and similar things like par), which provide similar functionality in python in a managed way.

Usage would be

python foo/setup.py bdist_xar && scp foo/dist/foo.xar user@server

if my understanding is correct.

[1]: https://github.com/facebookincubator/xar

Then you don't have any metadata about what's installed nor a way to roll back. I'd rather have automation that runs "sudo yum update $MYPACKAGE".

Good point. We found ways to overcome these issues, but that's a tradeoff, for sure.

Right, its not magic to build such a tool. But until it exists, this is a benefit for Go. This is also why I keep using Tcl, with tclkit you can build single-file executables for you tcl programs.

Pyinstaller solves the problem for me, but it can (in some particular cases) be a real bitch to configure properly with your dependencies at first.

Such a tool now exists and is called nuitka. See my other comment. It's very mature and can be trusted even with compiled extensions.

Reply on news.ycombinator.com