It does replace pipenv. They might not mention it because it's not widely used these days; most pipenv users switched to poetry sometime over the last half-decade or so.

There is a request for `uv shell` or similar[0], but it's trickier than it looks, and even poetry gave up `poetry shell` in their recent 2.0 release.

[0]: https://github.com/astral-sh/uv/issues/1910

Use direnv for automatically creating, activating, and deactivating your virtual environments. I don't know how anyone lives any other way. Just put this in a .envrc file (substituting whichever python version you are using):

  layout python python3.12
  pip install --upgrade pip
  python -m pip install -r requirements.txt

Looks like direnv can be extended to use uv:

https://github.com/direnv/direnv/wiki/Python#uv

You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.

While working in Django projects, one would prefer to have an environment activarted to perform all kinds of django-admin commands, I certainly wouldn't want to do via `uv run`.

Also, `nvim` is started with an environment activated if you want all the LSP goodies.

`uv run` is good for some things, but I prefer to have my venv activated as well.

Soon uv will invlude a task runner that will take care of that use case but I get your point.

Care to elaborate? I'm not watching uv development closely, something that has been announced?

It is common to have a task runner to abstract away commands.

doit, poethepoet, just... They are simpler than builders like make or maeven, and more convenient than aliases.

E.g: i don't run ./manage.py runserver 0.0.0.0:7777, I run "just openserver".

Poetry, cargo and npm have support for this natively, and there is an open ticker for this in uv too.

So you would not do "uv run manage.py runserver" but "uv serve".

Yeah, I use that with `rye` now.

But still, it's not good enough for Django as there are too many management commands and I don't want to configure them in pyproject.toml file, especially since some of them take additional arguments... There is no point in using anything but django-admin command (I do have a wrapper around it, but the point remains) and that requires activated venv.

How exactly does `uv` determine which is "the" venv? Is it simply based on the working directory like the `direnv`/`autoenv`/etc. workflows others are describing here?

It does seem like people have use cases for running code in a different environment vs. the one being actively used to develop the package.

It uses the content of the UV_PROJECT_ENVIRONMENT var env, which defaults to .venv. If you pass --active, it can also look whatever is in VIRTUAL_ENV and CONDA_PREFIX.

You can also force an env passing a complete path to --python

I use autoenv, which runs a .env file when switching to a folder with it, and of course it has an activation command.