Fyn: An uv fork with new features, bug fixes, stripped telemetry

trollbridge

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.

tcbrah

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

bovermyer

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.

albinn

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.

worksonmine

Why prefix the settings `UV_CACHE_MAX_SIZE` and `UV_LOCKFILE` with `UV_` if they're new features? Makes no sense.

Bender

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?

dirkc

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?

fmajid

I'm worried about OpenAI enshittifying uv and ruff now they've acquired Astral, so it's good to have options.

lr1970

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.

jcattle

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.

derodero24

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.

skeledrew

Will be switching to this, or another fork, soon as I see decent stability.

e10v_me

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.

tfrancisl

Super tenuous to claim that the info being sent to package indices constitutes "telemetry". Very clear this is a clout chaser.

aguyonhn

non-solution to a non-problem