There was no "telemetry" in uv to begin with. They're just aiming for an emotional response. Read about the "telemetry" they removed and you'll find it funny.
Given the telemetry, how did uv ever get approved/adopted by the open source community to begin with, or did it creep in? Why isn't it currently burning in a fire?
I suspect that my normal workflows might just have evolved to route around the pain that package management can be in python (or any other ecosystem really).
In what situations are uv most useful? Is it once you install machine learning packages and it pulls in more native stuff - ie is it more popular in some circles? Is there a killer feature that I'm missing?
> 2. Centralized venv storage — keep .venvs out of your project dirs
I do not like this. virtual environments have been always associated with projects and colocated with them. Moving .venv to centralized storage recreates conda philosophy which is very different from pip/uv approach.
In any case, I am using pixi now and like it a lot.
I like it. Enjoyed having it with Conda, was sorry when it was lost with uv. Been a pain to search my projects and have irrelevant results that I then have to filter. Or to remember to filter in the first place. The venvs may be associated with the projects, but they're just extraneous clutter unless there's actually something to be done directly on them, which is very rare.
Pip doesn’t have any philosophy here. It doesn’t manage your virtualenv at all, and definitely doesn’t suggest installing dependencies into a working directory.
Putting the venv in the project repository is a mess; it mixes a bunch of third party code and artifacts into the current workspace. It also makes cleaning disk space a pain, since virtualenvs end up littered all over the place. And every time you “git clean” you have to bootstrap all over again.
Perhaps a flag to control this might be a good fit, but honestly, I always found uv’s workflow here super annoying.
One problem I have on my work machine is that it will do a blind backup of project directories. Useless .venv structure with thousands of files completely trashes the backup process. Having at least the flexibility to push the .venv to a cache location is useful. There was (is?) a uv issue about this similar use case (eg having a Dropbox/Onedrive monitored folder).
24 comments
[ 0.27 ms ] story [ 55.5 ms ] threadI assume mainstream uv development will go into maintenance mode now, so it’s great to see a quality lineage like this.
Crazy that there is not way in uv to limit the cache size. I have loved using uv though, it is a breath of fresh air.
In what situations are uv most useful? Is it once you install machine learning packages and it pulls in more native stuff - ie is it more popular in some circles? Is there a killer feature that I'm missing?
> 2. Centralized venv storage — keep .venvs out of your project dirs
I do not like this. virtual environments have been always associated with projects and colocated with them. Moving .venv to centralized storage recreates conda philosophy which is very different from pip/uv approach.
In any case, I am using pixi now and like it a lot.
Putting the venv in the project repository is a mess; it mixes a bunch of third party code and artifacts into the current workspace. It also makes cleaning disk space a pain, since virtualenvs end up littered all over the place. And every time you “git clean” you have to bootstrap all over again.
Perhaps a flag to control this might be a good fit, but honestly, I always found uv’s workflow here super annoying.
And the first two commits are "new fork" and "fork", where "new fork" is a nice (+28204 -39206) commit and "fork" is a cheeky (+23971 -23921) commit.
I think I'm good. And I would question the judgement of anyone jumping on this fork.