You can't just create yourself an "everything" environment with UV and then experiment with it? Honest question.
I think you're basically suggesting that you'd have a VM or something that has system-high packages already preinstalled and then use UV on top of it?
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.
> 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".
> 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.
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.
> 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.
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
libmamba solved this year's ago. The dep solver is now much faster.
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
I think that user (like me until finding out just now) didn't know that you could make ad-hoc virtual environments with uv, and that instead you would have to make a directory with a pyproject.toml and install things into it by adding to that pyproject.toml
You can, but an "everything environment" is rarely to be recommended. How to do it: Make uv use the --active environment to install things. Before using uv, activate that environment.