zlacker

uv + the new way of adding the required packages in the comments is pretty good.

you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment.

Still no match for Go though, shipping a single cross-compiled binary is a joy. And with a bit of trickery you can even bundle in your whole static website in it :) Works great when you're building business logic with a simple UI on top.

>>theshr+(OP)
I've been out of the Python game for a while but I'm not surprised there is yet another tool on the market to handle this.

You really come to appreciate when these batteries are included with the language itself. That Go binary will _always_ run but that Python project won't build in a few years.

>>theshr+(OP)
> you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment.

Yeah, but you still have to install `uv` as a pre-requisite.

And you still end up with a virtual environment full of dependency hell.

And then of course we all remember that whole messy era when Python 2 transitioned to Python 3, and then deferred it, and deferred it again....

You make a fair point, of course it is technically possible to make it (slightly) "cleaner". But I'll still take the Go binary thanks. ;-)

>>theshr+(OP)
uv is the new hotness now. Let us check back in 5 years...

>>richid+13
Unless it made use of CGO and has dynamic dependencies, always is a bit too much.

>>pjmlp+zm
Or the import path was someone's blog domain that included a <meta> reference to the actual github repo (along with the tag, IIRC) where the source code really lives. Insanity

>>mdanie+jB
I never understood the mentality to have SCM urls as package imports directly on the source code.

>>tracer+L3
Installing uv is a requirement and incredibly easy.

No, there is no dependency hell in the venv.

Python 2 to 3: are you really still kicking that horse? It's dead...please move on.

>>pjmlp+kD
Well, that's the problem I was highlighting - golang somehow decided to have the worst of both worlds: arbitrary domains in import paths and then putting the actual ref of the source code ... elsewhere

  import "gopkg.in/yaml.v3" // does *what* now?

  curl https://gopkg.in/yaml.v3?go-get=1 | grep github
  <meta name="go-source" content="gopkg.in/yaml.v3 _ https://github.com/go-yaml/yaml/tree/v3.0.1{/dir} https://github.com/go-yaml/yaml/blob/v3.0.1{/dir}/{file}#L{line}">

oh, ok :-/

I would presume only a go.mod entry would specify whether it really is v3.0.0 or v3.0.1

Also, for future generations, don't use that package https://github.com/go-yaml/yaml#this-project-is-unmaintained