I 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.
> 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.
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).
thats my biggest problem with uv, i liked the way pipenv did it much better. I want to be able to use find and recursive grep without worrying that libraries are in my project directory.
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.
Disagree—better to have space allocated in each project where they can be easily deleted at once. Rather than half hidden in your home folder somewhere with random names and forgotten about.
If for some rare reason you wanted to delete all venvs, a find command is easy enough to write.
pixi is a general multi-languge, multi-platform package manager. I am using it now on my new macbook neo as a homebrew _replacement_. Yes, it goes beyond python and allows you to install git, jj, fzf, cmake, compilers, pandoc, and many more.
For python, pixi uses conda-forge and PyPI as package repos and relies on uv's rattler dependency resolver. pixi is as fast as uv (it uses fast code path from uv) but goes further beyond python wheels.
For detail see [0] or google it :-)
There is a good chunk of overlap but mise predominately pulls from github releases artifacts/assets and pixi uses conda packages. While mise can use conda packages, the mise-conda backend is still experimental. I don't think github releases or conda packages are better than the other, they both have tradeoffs.
Pixi is very python focused, it's both a tool manager and a library dependency manager (see uv/pip). Mise considered library dependency an anti-goal for a long time, while I don't see that on the website anymore I haven't seen any movement to go into that space.
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.
> 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.
This 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.
Do you only work on projects individually? Without project-specific environments I don’t know how you could share code with someone else without frequent breakages.
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?
The field that guesses if something is running in a CI environment is particularly useful, because it helps package authors tell if their package is genuinely popular or if it's just being installed in CI thousands of times a day by one heavy user who doesn't cache their requirements.
Honestly, stripping this data and then implying that it was collected by Astral/OpenAI in a creepy way is a bad look for this new fork. They should at least clarify in their documentation what the "telemetry" does so as not to make people think Astral were acting in a negative way.
Personally I think stripping the telemetry damages the Python community's ability to understand the demographics of package consumption while not having any meaningful impact on end-user privacy at all.
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.
Any telemetry should be done after explicit user consent, period. The harm is that you normalize total surveillance with these little, seemingly innocent steps.
I 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.
> 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.
I imagine it's just that the User-Agent is something that we've grown accustomed to passing information in. I am fairly biased since I'd always opt-in even to popcon. I think it's useful to have such usage information.
This is so useful, I'm shocked they even make a big thing out of it. And now I'm questioning whether this is even their real intention, or just a diversion?
Theyre saying "we removed telemetry" with the hopes of getting an emotional response from people who are privacy-focused, to get quick stars/attention.
On 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.
If 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.
> 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?
Recording information about someone's computer and then sending it to the developer without their knowledge or consent is spying. If you want to include a feature in the software to report a bug or collect crash info or whatever that tells the user what it's going to send and gets their affirmative consent, then yeah that's totally fine and not spying, but that's not what we appear to be talking about here. To use your analogy,
> 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.
That might be true, but it doesn't justify sticking a camera in their pantry to find out.
I will always have a "knee-jerk" response to opt-out or mandatory telemetry or any other outbound connections I did not ask for being initiated automatically. In a corporate world I would have to block this and depending on what the telemetry is connecting to that could impact other outbound connections leading to contention without the org.
One of the optimal ways to do this would be to opt-in by setting an environment variable to enabled any combination of extra debugging, telemetry, stats, etc... Perhaps even different end-points using environment variables.
Are you saying that when you tell uv to install a package you aren't asking it to make outbound connections to download the package from PyPI? The telemetry in question is just setting an appropriate User-Agent header with only slightly more data than what browsers traditionally put there. It does not make extra network requests purely for the sake of reporting information.
If I understand the description of this „telemetry“ in fyns „MANIFESTO.md“ correctly, it does not make outbound connections you did not asked for. It sets the user agent http header to something that identifies your OS, CPU, python version and if you are running in Ci when communicating to the package registry. It does not send any of that to astral, not ist any of that highly personal.
Sure, it should not be there by default, especially OS & CPU imho. But it’s not really what I’d call „invasive telemetry“.
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?
If 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.
Not really. I have good backups and I try to stick with dependencies I trust.
I do a lot of my development work using Claude Code for web which means stuff runs in containers on Anthropic's servers, but I run things on my laptop most days as well.
I 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!
So 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?
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.
> 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:
> 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.
I 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.
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.
I 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.
absolutely, but i like the spirit behind it. Hopefully we get a few more and one of them pulls ahead.
creator is definitely just jumping on this for some clout
based on that, the project description is entirely a lie - there are no bugfixes, new features, or even the removed telemetry here ?
Commit messages say a lot about people.
They really do. Let me cite another one from the repo:
"fix: updated readme. sorry was so tired i accidentally mass replaced uv with fyn for all"
Branch names do, too!
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.
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.
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).
Here's where that feature was (and is still being) discussed in the uv repo: https://github.com/astral-sh/uv/issues/1495
It's been open for two years but it looks like there's a PR in active development for it right now: https://github.com/astral-sh/uv/pull/18214
thats my biggest problem with uv, i liked the way pipenv did it much better. I want to be able to use find and recursive grep without worrying that libraries are in my project directory.
uv is just so fast that i deal with it.
rg/fd respect gitignore automatically which solves this problem
Ill check them out, thanks!
…but I don’t have everything in a git repo. Some of my “projects” are just local scraps for trying things out.
And it doesn’t account for any other tooling that may not respect gitignore by default.
it’s my biggest problem with npm too. Ive worked around it long enough, it’s just annoying.
rg also ignores "hidden" files by default (files/dirs starting with a period), so it will ignore .venv regardless if it's in a repo.
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.
Disagree—better to have space allocated in each project where they can be easily deleted at once. Rather than half hidden in your home folder somewhere with random names and forgotten about.
If for some rare reason you wanted to delete all venvs, a find command is easy enough to write.
Sometimes I want the venvs to be in a centralized location, and just do:
UV_PROJECT_ENVIRONMENT=$HOME/.virtualenvs/{env-name} uv {command}
How is pixi better than uv?
> How is pixi better than uv?
pixi is a general multi-languge, multi-platform package manager. I am using it now on my new macbook neo as a homebrew _replacement_. Yes, it goes beyond python and allows you to install git, jj, fzf, cmake, compilers, pandoc, and many more.
For python, pixi uses conda-forge and PyPI as package repos and relies on uv's rattler dependency resolver. pixi is as fast as uv (it uses fast code path from uv) but goes further beyond python wheels. For detail see [0] or google it :-)
[0] https://pixi.prefix.dev/latest/
How is it different than mise?
There is a good chunk of overlap but mise predominately pulls from github releases artifacts/assets and pixi uses conda packages. While mise can use conda packages, the mise-conda backend is still experimental. I don't think github releases or conda packages are better than the other, they both have tradeoffs.
Pixi is very python focused, it's both a tool manager and a library dependency manager (see uv/pip). Mise considered library dependency an anti-goal for a long time, while I don't see that on the website anymore I haven't seen any movement to go into that space.
They are all anachronisms, as they have no GUIs, just commands to be typed into a REPL.
It has been working fine for build systems like cargo.
I 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.
> 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.
This 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.
Do you only work on projects individually? Without project-specific environments I don’t know how you could share code with someone else without frequent breakages.
[dead]
Super tenuous to claim that the info being sent to package indices constitutes "telemetry". Very clear this is a clout chaser.
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?
The telemetry they removed here isn't unique to uv, and it's not being sent back to Astral. Here's the equivalent code in pip itself: https://github.com/pypa/pip/blob/59555f49a0916c6459755d7686a...
It's providing platform information to PyPI to help track which operating systems and platforms are being used by different packages.
The result is useful graphs like these: https://pypistats.org/packages/sqlite-utils and https://pepy.tech/projects/sqlite-utils?timeRange=threeMonth...
The field that guesses if something is running in a CI environment is particularly useful, because it helps package authors tell if their package is genuinely popular or if it's just being installed in CI thousands of times a day by one heavy user who doesn't cache their requirements.
Honestly, stripping this data and then implying that it was collected by Astral/OpenAI in a creepy way is a bad look for this new fork. They should at least clarify in their documentation what the "telemetry" does so as not to make people think Astral were acting in a negative way.
Personally I think stripping the telemetry damages the Python community's ability to understand the demographics of package consumption while not having any meaningful impact on end-user privacy at all.
Here's the original issue against uv, where the feature was requested by a PyPI volunteer: https://github.com/astral-sh/uv/issues/1958
Update: I filed an issue against fyn suggesting they improve their documentation of this: https://github.com/duriantaco/fyn/issues/1
Now people on HN defend telemetry. How did we come to this point?
Don't be surprised when you're asked to drink control bottle in order to continue living.
Explain 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_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.
Any telemetry should be done after explicit user consent, period. The harm is that you normalize total surveillance with these little, seemingly innocent steps.
That's a solid answer, thanks.
I 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.
> 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.
I imagine it's just that the User-Agent is something that we've grown accustomed to passing information in. I am fairly biased since I'd always opt-in even to popcon. I think it's useful to have such usage information.
This is so useful, I'm shocked they even make a big thing out of it. And now I'm questioning whether this is even their real intention, or just a diversion?
Theyre saying "we removed telemetry" with the hopes of getting an emotional response from people who are privacy-focused, to get quick stars/attention.
It was really really good.
Telemetry 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.
On 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.
That'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.
If 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.
> 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?
Recording information about someone's computer and then sending it to the developer without their knowledge or consent is spying. If you want to include a feature in the software to report a bug or collect crash info or whatever that tells the user what it's going to send and gets their affirmative consent, then yeah that's totally fine and not spying, but that's not what we appear to be talking about here. To use your analogy,
> 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.
That might be true, but it doesn't justify sticking a camera in their pantry to find out.
> Recording information about someone's computer and then sending it to the developer without their knowledge or consent is spying.
That's why I said done properly. You need full transparency. What is recorded and why, and how is the information dealt with.
In practice most people don't care. If they did they would disable all achievements, because even achievements are a form of telemetry.
You can see what percent of people finished the game for example. What percent played mini game, etc.
Anything that reveals remote metrics, is telemetry.
Because not everyone has a knee-jerk emotional reaction to a word when that word can mean something benign aside from its typical FUD connotation.
I will always have a "knee-jerk" response to opt-out or mandatory telemetry or any other outbound connections I did not ask for being initiated automatically. In a corporate world I would have to block this and depending on what the telemetry is connecting to that could impact other outbound connections leading to contention without the org.
One of the optimal ways to do this would be to opt-in by setting an environment variable to enabled any combination of extra debugging, telemetry, stats, etc... Perhaps even different end-points using environment variables.
Are you saying that when you tell uv to install a package you aren't asking it to make outbound connections to download the package from PyPI? The telemetry in question is just setting an appropriate User-Agent header with only slightly more data than what browsers traditionally put there. It does not make extra network requests purely for the sake of reporting information.
If I understand the description of this „telemetry“ in fyns „MANIFESTO.md“ correctly, it does not make outbound connections you did not asked for. It sets the user agent http header to something that identifies your OS, CPU, python version and if you are running in Ci when communicating to the package registry. It does not send any of that to astral, not ist any of that highly personal.
Sure, it should not be there by default, especially OS & CPU imho. But it’s not really what I’d call „invasive telemetry“.
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?
If 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.
Do you run those projects on the host system as your normal user without any isolation?
Yes, which makes me very vulnerable to supply chain attacks.
Yikes! I had a scare once, and since then I only run sandboxed code or scripts I've written with minimal 3rd party deps.
I assume you have other mitigations in place?
Not really. I have good backups and I try to stick with dependencies I trust.
I do a lot of my development work using Claude Code for web which means stuff runs in containers on Anthropic's servers, but I run things on my laptop most days as well.
Imo, uv scripts with the dependencies in the header.
https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
I 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!
So 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?
UV is most useful because it is so much faster than everything else. All the other features I could do without.
Yep, the speed is nice, I can't argue with that!
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.
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.
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.
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
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.
> 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-...
> 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.
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.
Would be more logical to use FYN_ prefix
They are environment variables. I enjoy seeing from my large number of environment variables to which applications they belong to.
I 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.
Ah, 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.
Facilitates drop-in migration from uv to the new tool. So if uv adopts the feature it's "just there".
non-solution to a non-problem
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.