Super tenuous to claim that the info being sent to package indices constitutes "telemetry". Very clear this is a clout chaser.
From fyn's roadmap:
> 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.
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'm surprised by how many people has fallen for that. I also wonder how many of them are the author's friends or bots.
As someone shipping native Node addons, registry telemetry (OS, arch, platform) is one of the few ways I know which build targets to actually prioritize. Without it I'd be guessing whether anyone's even using linux-arm64-musl. I get the instinct to strip it, but for package maintainers it's genuinely useful data.
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?
The shell and upgrade commands are helpful, especially when onboarding someone who has not used uv before.
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.
love that "we removed the telemetry" is now a headline feature worth forking an entire project over. says a lot about where dev tooling is headed tbh
I like the direction this fork is going in. I will wait to use it until it achieves a little more critical mass in adoption, though.
Looks great, and in particular, uv’s cache growing forever and lack of the uv shell command were both maddening.
I assume mainstream uv development will go into maintenance mode now, so it’s great to see a quality lineage like this.
Why prefix the settings `UV_CACHE_MAX_SIZE` and `UV_LOCKFILE` with `UV_` if they're new features? Makes no sense.
Will be switching to this, or another fork, soon as I see decent stability.
I'm worried about OpenAI enshittifying uv and ruff now they've acquired Astral, so it's good to have options.
Nah sorry, so far 4 of the 9 commit messages in that fork are "cleanup".
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.