Add option to auto-activate uv

[leiserfg]

No description provided.

[domenkozar]

Shouldn't that be on by default?

[leiserfg]

I just mimicked the options of poetry, uv environment does not need to be active, one can always use it via uv run python something is just not very ergonomic.

[leiserfg]

Now I'm double-checking the code, and maybe the problem happens because the task to sync uv, happens before the one for activating venv? that would explain why uv is not using the correct python (it is lacking the libraries defined in libraries).

[domenkozar]

Can you provide a way to reproduce the issue?

[wgordon17]

FWIW, I get around this with using venv to create the virtual environment, and then uv just reuses that environment

  languages.python = {
    enable = true;
    package = pkgs.python312Full;
    venv.enable = true;
    uv = {
      enable = true;
      sync.enable = true;
    };
  };

[abelREK]

@wgordon17 This does not seem to work properly with devenv shell. On a fresh system without using direnv to load in first, uv will not install the packages.

[LorenzBischof]

The following works:

{ pkgs, ... }:
{
  languages.python = {
    enable = true;
    uv.enable = true;
    uv.sync.enable = true;
  };
  enterShell = ''
    source $DEVENV_STATE/venv/bin/activate
  '';
}

The issue is that the devenv:python:virtualenv task, that runs after devenv:python:uv recreates the virtualenv with uv venv $DEVENV_STATE/venv.

[domenkozar]

The following works:

{ pkgs, ... }:
{
  languages.python = {
    enable = true;
    uv.enable = true;
    uv.sync.enable = true;
  };
  enterShell = ''
    source $DEVENV_STATE/venv/bin/activate
  '';
}

The issue is that the devenv:python:virtualenv task, that runs after devenv:python:uv recreates the virtualenv with uv venv $DEVENV_STATE/venv.

should we instead be just sourcing?

[LorenzBischof]

Yes, as far as I understand uv can be used either with a requirements.txt or with a uv.lock file. When using the lock file uv sync creates the virtualenv and we only have to source it.

[leiserfg]

The following works:

{ pkgs, ... }:
{
  languages.python = {
    enable = true;
    uv.enable = true;
    uv.sync.enable = true;
  };
  enterShell = ''
    source $DEVENV_STATE/venv/bin/activate
  '';
}

The issue is that the devenv:python:virtualenv task, that runs after devenv:python:uv recreates the virtualenv with uv venv $DEVENV_STATE/venv.

That's what I'm doing locally, but I think it's better to have it as an option, that's the reason for the pr.

[LorenzBischof]

Yes, I know. I only looked at your changes after posting my comment. It was in reply to @wgordon17, because that was the workaround I was previously using.

Is there anything that speaks against automatically sourcing if uv.sync is activated?

[leiserfg]

Maybe not wanting to "activate" the venv, as some may like to use uv run <script>. Also, to have a similar api as languages.python.poetry.activate.enable = true;

[LorenzBischof]

I think instead of adding a new option, we should fix venv.enable. If uv.sync is acivated it should not create a new virtualenv with uv venv and only source it.