> Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable.

I still do because:

- Go gives me a single binary

- Dependencies are statically linked

- I don’t need any third-party libs in most scenarios

- Many of my scripts make network calls, and Go has a better stdlib for HTTP/RPC/Socket work

- Better tooling (built-in formatter, no need for pytest, go vet is handy)

- Easy concurrency. Most of my scripts don’t need it, but when they do, it’s easier since I don’t have to fiddle with colored functions, external libs, or, worse, threads.

That said, uv is a great improvement over the previous status quo. But I don’t write Python scripts for reasons that go beyond just tooling. And since it’s not a standard tool, I worry that more things like this will come along and try to “improve” everything. Already scarred and tired in that area thanks to the JS ecosystem. So I tend to prefer stable, reliable, and boring tools over everything else. Right now, Go does that well enough for my scripting needs.

Very nice, I believe Rust is doing something similar too which is where I initially learned of this idea of single-file shell-type scripts in other languages (with dependency management included, which is how it differs from existing ways of writing single-file scripts in e.g. scripting languages) [0].

Hopefully more languages follow suit on this pattern as it can be extremely useful for many cases, such as passing gists around, writing small programs which might otherwise be written in shell scripts, etc.

[0] https://rust-lang.github.io/rfcs/3424-cargo-script.html

If PEP 723 is only an enhancement proposal does it work only because `uv` happens to support it?

Can you not use `uvx` with your script because it only works on packages that are installed already or on PyPi?

I have the same problem and have started using https://raindrop.io

Hope it serves you well