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.
> 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.
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
uv is just so fast that i deal with it.
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.
If for some rare reason you wanted to delete all venvs, a find command is easy enough to write.
UV_PROJECT_ENVIRONMENT=$HOME/.virtualenvs/{env-name} uv {command}
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.
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.
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 :-)
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
Don't be surprised when you're asked to drink control bottle in order to continue living.
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.
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.
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?
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.
https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
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 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.
I assume mainstream uv development will go into maintenance mode now, so it’s great to see a quality lineage like this.
