Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

Post reply on HN
Print view View original

151–160 of 231 posts

Re: Fun with uv and PEP 723

#151

Post by deepakjois »

rednafi wrote: post #142

> 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 i…

(author of post here)

I still use both Go and Python. But Python gives me access to a lot more libraries that do useful stuff. For example the YouTube transcript example I wrote about in the article was only possible in Python because afaik Go doesn't have a decent library for transcript extraction.

Re: Fun with uv and PEP 723

#152

Post by KingMob »

wazzaps wrote: post #99
ACAVJW4H wrote: post #12

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended ti…

Check out mise: https://mise.jdx.dev/ We use it at $work to manage dev envs and its much easier than Docker and Nix. It also installs things in parallel, which is a huge bonus over plain Dockerfiles

I declared nix bankruptcy earlier this year and moved to mise. It does 90% of what I need for only 1% of the effort of nix.

Re: Fun with uv and PEP 723

#153

Post by maccard »

bigstrat2003 wrote: post #21
ACAVJW4H wrote: post #12

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended ti…

> Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. IMO it should stay that way, because any script that needs those things is way past the point where shell is a reasonable choice. Shell scripts should be small, 20 lines or so. The language just plain sucks too much to make it worth using for anything bigger.

Unfortunately there’s basically no guarantee that even the simplest scripts work.

    #!/bin/bash
    make $1
Has multiple possible problems with it.

Re: Fun with uv and PEP 723

#154

Post by silverwind »

puika wrote: post #78

Like the author, I find myself going more for cross-platform Python one-offs and personal scripts for both work and home and ditching Go. I just wish Python typechecking weren't the shitshow it is. Looking forward to ty, pyrefly, etc. to improve the situation a bit

I do hope the community will converge on one type checker like ty. The fact that multiple type checkers exist is really hindering to the language as a whole.

Re: Fun with uv and PEP 723

#155

Post by rednafi »

7bit wrote: post #149
rednafi wrote: post #142

> 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 i…

Good for you. I dont See how this is relevant to this topic.

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

Here's how it's relevant :)

Re: Fun with uv and PEP 723

#156

Post by rednafi »

deepakjois wrote: post #151
rednafi wrote: post #142

> 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 i…

(author of post here) I still use both Go and Python. But Python gives me access to a lot more libraries that do useful stuff. For example the YouTube transcript example I wrote about in the article was only possible in Python because afaik Go doesn't have a decent library for transcript extraction.

Yeah that's a fair point. I still do a ton of Python for work. The language is fine; it's mostly tooling that still feels 30 years old.

Re: Fun with uv and PEP 723

#157

Post by ndr »

est wrote: post #125
ACAVJW4H wrote: post #12

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended ti…

> finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Hmm, last time I checked, uv installs into ~/.local/share/uv/python/cpython-3.xx and can not be installed globally e.g. inside a minimal docker without any other python. So basically it still runs in a venv.

https://docs.astral.sh/uv/reference/settings/#pip_system

Re: Fun with uv and PEP 723

#158

Post by pjc50 »

gerdesj wrote: post #105

I've recently updated a Python script that I originally wrote about 10 years ago. I'm not a programmer - I just have to get stuff done - think sysops. For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept. When Python first came out, our processor…

> For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept.

Eh. There's a lot of space in the middle to "well actually" about, but Python really doesn't behave like a "compiled" language. The more important question is: what do you ship to people, and how easily can they use it? Lots of people in this thread are bigging up Go's answer of "you ship a thing which can run immediately with no dependencies". For users that solves so many problems.

Quite a few python usecases would benefit from being able to "compile" applications in the same sense. There are py-to-exe solutions but they're not popular or widely used.

Re: Fun with uv and PEP 723

#159

Post by pjc50 »

AstroJetson wrote: post #52

> uv is an extremely fast Python package and project manager, written in Rust. Is there a version of uv written in Python? It's weird (to me) to have an entire ecosystem for a language and a highly recommended tool to make your system work is written in another language.

uv wins precisely because it isn't written in python. As various people have pointed out, it can complete its run before competing python implementations have finished handling their imports.

Besides, the most important tool for making python work, the python executable itself, is written in C. People occasionally forget it's not a self-hosting language.

Re: Fun with uv and PEP 723

#160

Post by mmcnl »

jkingsman wrote: post #2

uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Python scripts from Github super easily. No git clone, no venv creation + entry + pip install. And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than…

I agree uv is amazing, but it's not a virtual machine, it's a virtual environment. It runs the scripts on top of your OS without any hardware virtualization. The virtual environment only isolates the Python dependencies.
Post reply on HN