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.

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.

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?

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.

[dead]