I'm stuck on poetry until Snyk adds support for uv. Ugh. If anyone from Snyk is reading this, please go yell at whoever Jacob is: https://support.snyk.io/s/question/0D5PU00000u1G4n0AE/suppor...
Semgrep has supported uv for months now (I added it).
Uv overtakes pip in CI
121–130 of 184 posts
Re: Uv overtakes pip in CI
#122Earlier quoted context omitted.
If it sold itself on its merits I don’t think we’d see all these fawning posts about it. It’s a Rust fan thing. You can see how any criticism gets treated. I’m sure it works for some people and obviously if it does, then great. But it’s got this same weird cult following and pretend talk of speed that lots of Rust stuff has. It’s getting a little tiring. If you like it, use it, evangelizing is obnoxious.
What’s more obnoxious is dismissing it as a rust fanboy conspiracy. Know what I like about it? `uv install .` with a few dozen top-level dependencies takes under a second on my machine. All the tools work as documented all the time. `uv run …` is nearly instant. Those are the reasons I like it. I couldn’t care less that it’s written in rust. It could be conjured from malbolge for all I care. It works as advertised, w…
As an occasional Python user that loves uv -- I do care that it's in Rust, because Rust enforces a separation between mutable and immutable state that consistently leads to higher-quality outcomes.
Re: Uv overtakes pip in CI
#123Earlier quoted context omitted.
What’s more obnoxious is dismissing it as a rust fanboy conspiracy. Know what I like about it? `uv install .` with a few dozen top-level dependencies takes under a second on my machine. All the tools work as documented all the time. `uv run …` is nearly instant. Those are the reasons I like it. I couldn’t care less that it’s written in rust. It could be conjured from malbolge for all I care. It works as advertised, w…
As an occasional Python user that loves uv -- I do care that it's in Rust, because Rust enforces a separation between mutable and immutable state that consistently leads to higher-quality outcomes.
I don’t totally not care that it’s written in Rust. That means there are whole classes of bugs it won’t have, and it’s probably rigorous about data structure and state management.
Re: Uv overtakes pip in CI
#124Earlier quoted context omitted.
What’s more obnoxious is dismissing it as a rust fanboy conspiracy. Know what I like about it? `uv install .` with a few dozen top-level dependencies takes under a second on my machine. All the tools work as documented all the time. `uv run …` is nearly instant. Those are the reasons I like it. I couldn’t care less that it’s written in rust. It could be conjured from malbolge for all I care. It works as advertised, w…
I use golang, rust and c++ here and there, but majority of my time is spent working in Python projects. I'm not alien to the concept of speed and performance, especially the tooling around them. While I like the idea of pip or uv to be insanely fast, I still don't see it revolutionize my development experience. Installing and uninstalling package is not something I do every 1 to 10 minutes. It doesn't save me any muc…
The speed is nice. It’s not the only advantage, though. It’s so pleasant being able to `uv run [git-repo]` and having it work. The same design that makes it so fast makes it delightfully good at doing other complicated things.
Re: Uv overtakes pip in CI
#125Earlier quoted context omitted.
> (unless you like using an env in your container that is). What's the problem with that? You just make your script's entry point be something like this: uv venv --clear uv sync uv run main.py
Doesn’t this mean pid 0 in the container is uv instead of python? Does uv run just spawn a child python process?
> Does uv run just spawn a child python process?
Yes, I suppose you could use it in conjunction with something like https://github.com/krallin/tini.
Re: Uv overtakes pip in CI
#126I seriously still don't know why I should use "uv". I just create my .venv and pip install. Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv. I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part. I'm not sure how big a project should be, before I feel pip is slow for me. Currently, I hav…
A sure way to learn why it is needed would be to: 1. Write code that crosses a certain complexity treshold. Let's say tou also need compiled wheels for a performance critical section of a library that was written in Rust, have some non-public dependencies on a company-internal got server 2. Try deploying said code on a fleet of servers whose version and exact operating system versions (and python versions!) are total…
This explains a lot for me. On the server side, all my for-pay stuff is deployed using Docker. We have a single Python environment and complete control over it. We do multistage for compilation.
Client side, we don't get the privilege of deploying code: we need to build installers, which means again we have complete control over the environment because we package Python and all associated dependencies.
I'm sure there are marginal benefits to uv even with the above scenarios (better dependency management for example), but it seems that there's a middle ground here which I have largely avoided which is where uv really shines.
Re: Uv overtakes pip in CI
#127Earlier quoted context omitted.
It’s a little too fast, I’m having trouble believing it’s actually doing anything sometimes.
uv is so over-the-top fast compared to what we're used to that I would argue it's actually bad for the language. Suddenly it dawns on you that by far the most capable and performant package manager (and linter) (and code formatter) (and type checker) for Python is in fact not written in Python. Leaves an odd taste. Makes you wonder what else ought not be written in Python ... or why anything should be written in Pyth…
Well Python isn't written in python either.
Re: Uv overtakes pip in CI
#128I seriously still don't know why I should use "uv". I just create my .venv and pip install. Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv. I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part. I'm not sure how big a project should be, before I feel pip is slow for me. Currently, I hav…
So you always have your deps' versions tracked, like in npm
Re: Uv overtakes pip in CI
#129Earlier quoted context omitted.
If it sold itself on its merits I don’t think we’d see all these fawning posts about it. It’s a Rust fan thing. You can see how any criticism gets treated. I’m sure it works for some people and obviously if it does, then great. But it’s got this same weird cult following and pretend talk of speed that lots of Rust stuff has. It’s getting a little tiring. If you like it, use it, evangelizing is obnoxious.
Yeah, but it sold itself on its merrits. That is the point. Maybe venv and pip works fine for some toy projects that are deployed on the developer controlled OS without regular dependency updates, but let me assure you I had hours of fights with updating python services with complex needs on Debian boxes from various ages while ensuring whst I ran as a dev is the stuff that is guaranteed to run in production. With uv…
Also one has to chuckle at the notion that re-writing package management in Rust is some kind of fanbois with hammers looking for nails activism. Rust is almost certainly the best option for this in the 2020s, especially for a package ecosystem as deranged as Python's.
Re: Uv overtakes pip in CI
#130Earlier quoted context omitted.
Yeah, but it sold itself on its merrits. That is the point. Maybe venv and pip works fine for some toy projects that are deployed on the developer controlled OS without regular dependency updates, but let me assure you I had hours of fights with updating python services with complex needs on Debian boxes from various ages while ensuring whst I ran as a dev is the stuff that is guaranteed to run in production. With uv…
Also one has to chuckle at the notion that re-writing package management in Rust is some kind of fanbois with hammers looking for nails activism. Rust is almost certainly the best option for this in the 2020s, especially for a package ecosystem as deranged as Python's.
Could've been written in any other language and been just as good. Python needed something like this one way or another.