4 ms·

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

selectnull 2y ago
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.
- BiteCode_dev 2y ago
  Soon uv will invlude a task runner that will take care of that use case but I get your point.
  - selectnull 2y ago
    Care to elaborate? I'm not watching uv development closely, something that has been announced?
    - BiteCode_dev 2y ago
      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".
      - selectnull 2y ago
        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.
zahlman 2y ago
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.
- BiteCode_dev 2y ago
  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

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.

BiteCode_dev 2y ago
Soon uv will invlude a task runner that will take care of that use case but I get your point.
- selectnull 2y ago
  Care to elaborate? I'm not watching uv development closely, something that has been announced?
  - BiteCode_dev 2y ago
    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".
    - selectnull 2y ago
      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.

zahlman 2y ago

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.

BiteCode_dev 2y ago
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