Hacker News Reader

Comment by BrenBarn | Hacker News Reader

If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/

I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools).

You can use the `uv venv` and the `uv pip` stuff to create an environment and install stuff into it, but this isn't really different from normal venvs. And in particular it doesn't give me much benefit over conda/mamba.

I get that the project-based workflow is what a lot of people want, and I might even want it sometimes, but I don't want to be forced into foregrounding the project.

View on HN

> I don't want to be forced into foregrounding the project.

The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project, run uv install and get working. It's the death of "works on my machine" and "well it'll take them a couple of weeks to properly get up and running".

Sure, that's fine. I'm saying I just won't get to that stage until later.

A “project" is largely a way of storing the definition of the state of a environment in a config file (pyproject.toml). It does a bit more, but you can basically ignore that initially.

It takes a couple of seconds to setup, and then you just use uv add instead of (uv) pip install to add things to the environment, and the project file is kept in sync with the state of the environment. I'm not really understanding what it is for the workflow you describe that you expect a tool to do that uv isn’t providing?

Just professional software engineering practices.

> The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project

I know this might be a strange idea on HN, but tons of people writing code in Python, who need access to PyPI packages to do what they're doing, have no intention whatsoever of providing a clonable project to others, or sharing it in any other way, or indeed expecting anyone else on the planet to run the code.

> And in particular it doesn't give me much benefit over conda/mamba.

How about the advantage of not taking an entire lunch break to resolve the environment every time you go to install a new library?

That was the biggest sticking point with conda/mamba for me. It's been a few years since I last used them but in particular with geospatial packages I would often run into issues.

libmamba solved this year's ago. The dep solver is now much faster.

This is not the case anymore. With libmamba I've never waited more than a few minutes for resolving dependencies and installing. uv is faster for sure, but speed is no longer a big problem with conda

I assume if you stick a .venv in your home directory it'll essentially be available globally as you desired.. and overridden in project specific .venv or similar

Reply on news.ycombinator.com