Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

441–450 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#441
post #42

Earlier quoted context omitted.

If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this i…

If you’re executing a script from an untrusted source, you should be examining it anyway. If it fails to execute because you haven’t installed the correct dependencies, that’s an inconvenience, not a lucky security benefit. You can write a reverse shell in Python with no dependencies and just a few lines of code.

it's a stretch to "executing a script with a build user" or "from a validated distro immutable package" to "allowing something to download evergreen code and install files everywhere on the system".

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#442
post #354
post #239

Earlier quoted context omitted.

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have issues installing globally, especially since others keep telling me what a terrible idea it is and how they had nightmare-scenario-X happen to them.

They happen /all the time/.

For a long time there were even compatibilities between the RHEL host python version, and the python version the Red Hat Ansible team were shipping.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#443
post #354
post #239

Earlier quoted context omitted.

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have issues installing globally, especially since others keep telling me what a terrible idea it is and how they had nightmare-scenario-X happen to them.

I write Python code for a living and no two projects I work on have the exact same dependencies. This is especially true when working with microservices, or working for multiple customers.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#444
post #242
post #72

Earlier quoted context omitted.

Your implication is that pyenv, virtualenv, and pip should be 3 different tools. But for the average developer, these tools are all related to managing the python environment and versions which in my head sounds like one thing. Other languages don't have 3 different tools for this. pip and virtualenv also add a ton of complexity and when they break (which happens quite often) debugging it is even harder despite them…

I think OP's complaint is rather that using `uv` is leaky: now you need to learn all the underlying stuff AND uv as well. The alternative, of course, is having Python natively support a combined tool. Which you can support while also not liking `uv` for the above reason.

I don't think that's true, most projects using uv don't rely on those tools at all, and you don't need to understand them. You just `uv sync` and do your work.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#445

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.

> The script now works like a standalone executable

But whoever runs this has to install uv first, so not really standalone.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#446

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

conda was great to me

miniconda

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#447
post #239

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

That works, more or less. But now you have a requirements.txt file with 300 dependencies. Which ones do you actually care about, and which are just transitive things that your top-level deps brought along for the ride? And a year later, when GitHub's Dependabot is telling you have a security vulnerability in some package you've never heard of, do you remember if you even care about that package in the first place, or if it's left over cruft from that time you experimented with aiohttp instead of httpx?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#448

Earlier quoted context omitted.

poetry gave us lock files and consistent installs for years. uv is much, much faster however.

There was pipenv before that too, which also had a lockfile. Funny how these things get forgotten to history. There's lots of prior art when it comes to replacing pip. edit: here's an HN thread about pipenv, where many say the same things about it as they are about UV and Poetry before https://news.ycombinator.com/item?id=16302570

Except pipenv was never anywhere near as good. It meant well but never delivered.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#449
post #63
post #29

These rust based tools really change the idea of what's possible (when you can get feedback in milliseconds). But I'm trying to figure out what Astral as a company does for revenue. I don't see any paid products on their website. They even have investors. So far it seems like they have a bunch of these high performance tools. Is this part of an upcoming product suite for python or something? Just curious. I'm not a f…

From "So how does Astral plan to make money? " ( https://news.ycombinator.com/item?id=44358216 ): "What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. An example of what this might look like [...] would be something like an enterprise-focused pri…

hmm how well did that work for Docker ...

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#450

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

I used to think this sentiment was exaggerated. Then I tried installing Dots OCR. What a nightmare, especially when NVIDIA drivers are involved.
Post reply on HN