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?
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
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.
Those PyPI download numbers are one of the most useful hints as to whether my stuff is being used by anyone.
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.
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.
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.
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.
Sure, it should not be there by default, especially OS & CPU imho. But it’s not really what I’d call „invasive telemetry“.