Wrap Go binaries in Python wheels(github.com)
github.com
Wrap Go binaries in Python wheels
https://github.com/simonw/go-to-wheel
15 comments
Why wouldn't I just `go install` from the git repo? Why is it worth encouraging the use of python tooling for generic application distribution when things like homebrew or chocolatey already exist?
You would need to have go installed. For my golang opensource project, also added releases on pypi and also npm.
From what I recall, Simon believes non-technical people or developers new to an ecosystem (or lacking a specific toolchain) should be given options to use existing language-specific package repositories and package management tools to reduce friction while engaging in agentic coding.
I can see the rationale but I can't help thinking it's utterly absurd.
I can see the rationale but I can't help thinking it's utterly absurd.
What kind of "non-technical" person is fine with using "pip install …", but not "go install …"?
The kind of person who only knows Python or has learned a bit by following a Python tutorial. There are a lot more resources for people who are just starting to learn programming in Python. I can also see a use-case where there is an image with pip installed, but not any of the Golang packages.
It’s kind of niche, but I can see a place for it.
It’s kind of niche, but I can see a place for it.
Is uvx and python aware of GOOS / GOARCH when using this method? It looks like it, but also means you have to download all of the binaries instead of just the one you need?
I agree it is absurd, and then there has to be a python package one has to create, something go avoided by using the git repo URL directly
I agree it is absurd, and then there has to be a python package one has to create, something go avoided by using the git repo URL directly
See here [1] for more information on the rationale behind this.
[1] https://simonwillison.net/2026/Feb/4/distributing-go-binarie...
[1] https://simonwillison.net/2026/Feb/4/distributing-go-binarie...
This is still surprising! There are similar tools for rust, and presumably it works for arbitrary binaries. Can be a convenient installation approach if you expect your user base to use python. E.g. for distributing tools written in Go, Rust, C, etc that aid Python development. To the user, it's a standard `pip install x`, but x is not a python script.
I’m curious if I could use this to write my webserver in Go, then call back to Python for the data sciencey stuff over stdin(?), but all in one nice tidy package? I mean right now I use fastapi and write it all in Python but I happen to enjoy writing Go. Does it matter either way? No I have like 4 users, but it seems not too crazy either?
Why should I use python when I can just use Go? Like why
Because you can wrap Go binaries in Python wheels, but not yet Python wheels in Go binaries
You can embed a whole dir using //go:embed, also python exe for all architectures, then extract & run it at runtime. Python via WASI is also possible.
Read too fast, I was really hoping for a way to get a python app in a binary like in Go.