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?
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.
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’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?
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.
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?
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.
What kind of "non-technical" person is fine with using "pip install …", but not "go install …"?
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’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?
See here [1] for more information on the rationale behind this.
[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.
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
Read too fast, I was really hoping for a way to get a python app in a binary like in Go.
Hah; turns out this is precisely the opposite!
Python subsystem for Go