I have yet to learn uv, but I intend to. Still, having to ".venv/bin/activate" to activate the virtualenv is a lot less ergonomic than "pipenv shell".
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.
layout python python3.12
pip install --upgrade pip
python -m pip install -r requirements.txt
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.
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".
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.
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.
You can also force an env passing a complete path to --python