Hacker News Reader

Comment by iandanforth | Hacker News Reader

Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable.

You don't have to love uv, and there are plenty of reasons not to.

View on HN

> I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable.

TFA offers a myriad innovative and pleasing examples. It would have been nice if you actually commented on any of those, or otherwise explained why you think otherwise.

> soon to be dead set of patterns.

Dozens of threads of people praising how performant and easy uv is, how it builds on standards and current tooling instead of inventing new incompatible set of crap, and every time one comment pops up with “akshually my mix of conda, pyenv, pipx, poetry can already do that in record time of 5 minutes, why do you need uv? Its going to be dead soon”.

To be fair here: conda was praised as the solution to everything by many when it was new. It did have its own standards of course. Now most people hate it.

Every packaging PEP is also hailed as the solution to everything, only to be superseded by a new and incompatible PEP within two years.

So what?

If someone doesn’t want to use it, or doesn’t like it, or is, quite reasonably skeptical that “this time it’ll be different!” … let them be.

If it’s good, it’ll stand on its own despite the criticism.

If it can’t survive with some people disliking and criticising it is, it deserves to die.

Right? Live and let live. We don’t have to all agree all the time about everything.

uv is great. So use it if you want to.

And if you don’t, that’s okay too.

Naive take. https://gwern.net/holy-war counsels that, in fact, becoming the One True Package Manager for a very popular programming language is an extremely valuable thing to aim towards. This is even outside of the fact that `uv` is backed by a profit-seeking company (cf https://astral.sh/about). I'm all for people choosing what works best for them, but I'm also staunchly pro-arguing over it.

> becoming the One True Package Manager for a very popular programming language is an extremely valuable thing

For companies. Which is why when random people start acting like it’s important, you have to wonder why it’s important to them.

For example, being a corporate shill. Or so deep in coolaid you can’t allow alternative opinions? Hm?

It’s called an echo chamber.

Why on earth would it be only important for companies?

>Which is why when random people start acting like it’s important, you have to wonder why it’s important to them.

I don't use uv because I don't currently trust that it will be maintained on the timescales I care about. I stick with pip and venv, because I expect they will still be around 10 years from now, because they have much deeper pools of interested people to draw contributors and maintainers from, because - wait for it - they are really popular. Your theory about random people being corporate shills for anything they keep an eye on the popularity of can be explained much more parsimoniously like that.

conda user for 10 years and uv skeptic for 18 months.

I get it! I loved my long-lived curated conda envs.

I finally tried uv to manage an environment and it’s got me hooked. That a projects dependencies can be so declarative and separated from the venv really sings for me! No more meticulous tracking of a env.yml or requirements.txt just ‘uv add` and `uv sync` and that’s it! I just don’t think about it anymore

I'm also a long time conda user and have recently switched to pixi (https://pixi.sh/), which gives a very similar experience for conda packages (and uses uv under the hood if you want to mix dependencies from pypi). It's been great and also has a `pixi global` similar to `pipx`, etc the makes it easy to grab general tools like ripgrep, ruff etc and make them widely available, but still managed.

whoa! TIL thanks will check it out

Pip installs packages, but it provides rather limited functionality for actually managing what it installed. It won't directly spit out a dependency graph, won't help you figure out which of the packages installed in the current environment are actually needed for the current project, leaves any kind of locking up to you...

I agree that uv is the N+1th competing standard for a workflow tool, and I don't like workflow tools anyway, preferring to do my own integration. But the installer it provides does solve a lot of real problems that Pip has.

Yeah, I don't want my build tool to manage my Python, and I don't want my tool that installs Pythons to manage my builds.

In JVM land I used Sdkman to manage JVMs, and I used Maven or Gradle to manage builds.

I don't want them both tied to one tool, because that's inflexible.

What does the additional flexibility get you? It's just one less thing to worry about when coordinating with a team, and it's easy to shift between different versions for a project if need be.

Reply on news.ycombinator.com