python.uv.sync.enable and python.venv.enable have conflicting PATH exports

[mauricege]

Describe the bug
In order to have a python venv that is managed through uv, one has to set both languages.python.uv.sync.enable and languages.python.venv.enable to true. Since the tasks update, both define PATH as exports - however, the initUvScript does not activate the virtual environment and therefore its path does not include the venv at the front. This randomly leads to a .devenv/load-exports file in which PATH from "devenv:python:virtualenv" gets overwritten by the value from "devenv:python:uv" and therefore not correctly activating the venv.

I tried to fix it by setting:

{
   tasks."devenv:python:uv".before = ["devenv:python:virtualenv"];
}

But the order of the tasks does not seem to reflect the order of variable exports in .devenv/load-exports.

Removing "PATH" from the task exports of "devenv:python:uv" seems to work and I have not noticed any problems:

{
   tasks."devenv:python:uv".exports = lib.mkForce ["VIRTUAL_ENV"];
}

To reproduce
Minimal devenv.nix to reproduce:

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

Version
devenv 1.3.0 (x86_64-linux)

[domenkozar]

@mauricege could you try #1504

[mauricege]

@mauricege could you try #1504

Thanks for the quick response!

With these fixes I was unable to reproduce the error - at least after direnv reloading ~20 times.

However, I do not get how the order of devenv:python:virtualenv and devenv:python:uv is enforced? Is it alphabetical sorting?

[domenkozar]

The fixes makes sure that outputs order is respected, so we should tell uv to depend on virtualenv. Pushed a fix!