8 ms·
Fyn: An uv fork with new features, bug fixes, stripped telemetry
- stackedinserter 6mo ago[flagged]
- simonw 6mo agoExplain to me the harm that is caused to users of pip when this particular set of platform information is sent to PyPI. (In case you were going to say that it associates hardware platform details with IP addresses - which would have been my answer - know that PyPI doesn't record IPs: https://www.theregister.com/2023/05/27/pypi_ip_data_government/ https://www.theregister.com/2023/05/27/pypi_ip_data_governme... ) Then give me your version of why it's not reasonable for the Python packaging community (who are the recipients of this data, it doesn't go to Astral) to want to collect aggregate numbers against those platform details.
- stackedinserter 6mo agoAny telemetry should be done after explicit user consent, period. The harm is that you normalize total surveillance with these little, seemingly innocent steps.
- simonw 6mo agoThat's a solid answer, thanks.
- deleted 6mo ago[deleted]
- AlexeyBelov 6mo agoControl bottle? Do you mean validity flask?
- hrmtst93837 6mo ago[flagged]
- trollbridge 6mo agoLooks 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 6mo agolove 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
- tfrancisl 6mo agoThere 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.
- yjftsjthsd-h 6mo ago> 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. I would personally prefer it be spelled out better, but I assume we're looking at this: https://github.com/duriantaco/fyn/blob/main/MANIFESTO.md#no-telemetry--your-installs-are-your-business https://github.com/duriantaco/fyn/blob/main/MANIFESTO.md#no-... > uv was sending a surprising amount of info to package indexes every time you installed something. These things include your OS, py version, CPU architecture, Linux distro, whether you're in CI. All baked into the User-Agent header via something called "linehaul". We ripped that out. Now it just sends fyn/0.10.13. That's it. Unless you're disputing the factual angle (I confess I tried to look at the commits, saw that the first couple commits in the repo changed over a thousand files, and gave up)... yes? I would describe sending OS, python version, CPU arch, and CI yes/no as telemetry. I guess we can quibble about whether there's a more precise term for this particular form of sending information about your machine to a remote target without asking, but the description seems fair enough.
- bovermyer 6mo agoI 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 6mo agoThe 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 6mo agoWhy prefix the settings `UV_CACHE_MAX_SIZE` and `UV_LOCKFILE` with `UV_` if they're new features? Makes no sense.
- _flux 6mo agoThey are environment variables. I enjoy seeing from my large number of environment variables to which applications they belong to.
- worksonmine 6mo agoI know what an environment variable is, my question is why name them `UV_` instead of `FYN_`? I thought that would've been obvious for exactly the same reason you mention, it should be named for the application they belong to.
- _flux 6mo agoAh, I completely missed the point of your question :). Yes, I think that's a good point. Possibly they were made before the project name was changed and no further thought was given to them after.
- unethical_ban 6mo agoFacilitates drop-in migration from uv to the new tool. So if uv adopts the feature it's "just there".
- lr1970 6mo agoWould be more logical to use FYN_ prefix
- Bender 6mo agoGiven 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?
- albinn 6mo agoI don't think it is too bad, the telemetry it sends is quite rudimentary. However, would have been a good move from astral-sh to be open and explicit about it, and allow turning it off.
- Ygg2 6mo agoTelemetry isn't bad in OSS per se. Without it, it's hard to say how an app is used and how to develop it in the future.
- yjftsjthsd-h 6mo agoOn the contrary, OSS is precisely where this kind of spying on your users is least useful, since there's already a culture of them telling you, sometimes with code, what they need.
- simonw 6mo agoThat's not been my experience at all. The default response to open source code is stone cold silence - getting any feedback at all takes real effort. Those PyPI download numbers are one of the most useful hints as to whether my stuff is being used by anyone.
- Ygg2 6mo agoIf that's the issue, that's a problem. They are telling you X. People, if they tell you, don't give their honest feedback. Or they might be a loud minority. If you ask people what coffee they want, they will all tell you low-sugar, very bitter black coffee. Then you see what they buy, and they keep buying sugary and creamy coffee that contains almost no caffeine. Telemetry isn't spying. At least when done properly. How do you figure out rare OOM crashes without some telemetry data? What if the reporter doesn't know how to figure out their OS and installed software that's required for debugging? I'm NOT saying telemetry should capture everything and sell that data to info brokers. I'm saying, done properly it give you valuable feedback. And you should be transparent about it.
- dirkc 6mo agoI 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?
- dec0dedab0de 6mo agoUV is most useful because it is so much faster than everything else. All the other features I could do without.
- dirkc 6mo agoYep, the speed is nice, I can't argue with that!
- politelemon 6mo agoImo, uv scripts with the dependencies in the header. https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
- dirkc 6mo agoI guess that could be useful. I don't have many standalone python scripts, and those that I do have are very basic. It would be really nice if that header could include sandboxing!
- simonw 6mo agoSo much this! I've been bugging Astral about addressing the sandboxing challenge for a while, I wonder if that might take more priority now they're at OpenAI?
- simonw 6mo agoIf you have hundreds of different Python projects on your machine (as I do) the speed and developer experience improvements of uv make a big difference. I love being able to cd into any folder and run "uv run pytest" without even having to think about virtual environments or package versions.
- fmajid 6mo agoI'm worried about OpenAI enshittifying uv and ruff now they've acquired Astral, so it's good to have options.
- lr1970 6mo agoFrom 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.
- short_sells_poo 6mo agoI like it a lot :D. Virtual environments have been always associated with projects in your use case I guess. In my use case, they almost never are. Most people in my industry have 1-2 venvs that they use across all their projects, and uv forcing it into a single project directory made it quite inconvenient and unnecessary duplication of the same sets of libraries. I dislike conda not because of the centralized venvs, but because it's bloated, poorly engineered, slow and inconvenient to use. At the end of the day, this gives us choice. People can use uv or they can use fyn and have both use cases covered.
- lr1970 6mo ago> and uv forcing it into a single project directory made it quite inconvenient and unnecessary duplication of the same sets of libraries. Actually, uv intelligently uses hardlinks or reflinks to avoid file duplication. On the surface, venvs in different projects are duplicate, but in reality they reference the same files in the uv's cache. BTW, pixi does the same. And `pixi global` allows you to create global environments in central location if you prefer this workflow. EDIT: I forgot to mention an elephant in the room. With agentic AI coding you do want all your dependencies to be under your project root. AI agents run in sandboxes and I do not want to give them extra permissions pocking around in my entire storage. I start an agent in the project root and all my code and .venv are there. This provides sense of locality to the agent. They only need to pock around under the project root and nowhere else.
- mr_mitm 6mo agoThis is actually the feature that initially drew me towards uv. I never have to worry about where venvs live while suffering literally zero downsides. It's blazing fast, uses minimal storage, and version conflicts are virtually impossible.
- jcattle 6mo agoNah 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.
- emil-lp 6mo agoCommit messages say a lot about people.
- bjornarv 6mo agocreator is definitely just jumping on this for some clout
- deleted 6mo ago[deleted]
- albinn 6mo agoI agree, I like some of the directions the fork would go and dislike some. The apparent, fork, publish on HN, then change (and the change showing not a lot of understanding) makes me throughly question the legitimacy and long term stability of it.
- dec0dedab0de 6mo agoabsolutely, but i like the spirit behind it. Hopefully we get a few more and one of them pulls ahead.
- derodero24 6mo ago[flagged]
- skeledrew 6mo agoWill be switching to this, or another fork, soon as I see decent stability.
- e10v_me 6mo agoI'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 6mo agoSuper tenuous to claim that the info being sent to package indices constitutes "telemetry". Very clear this is a clout chaser.
- aguyonhn 6mo agonon-solution to a non-problem