Add support for latest uv project management features

[clementpoiret]

The current script generated to init env with uv checks for requirements.txt. However, uv now supports uv sync to deal with pyproject.toml, similarly to poetry. Cf https://astral.sh/blog/uv-unified-python-packaging

Based on the presence of a pyproject.toml, would it be possible to replace the workflows around requirements.txt with a simple uv sync call?

If you validate the approach, maybe I can work on a PR?

[domenkozar]

Maybe we should enable it if languages.python.poetry.enable is set to true?

[clementpoiret]

Since last uv's update, there are nearly no reason to have both poetry and uv I think, as uv aims at being a complete alternative to poetry-like tools, so if you have uv.enabled = true, you will want poetry.enabled = false.
What about simply changing the behavior implicitly based on the presence of a pyproject.toml file? Or make it explicit such as

uv = {
  enabled = true;
  use_pyproject = true;
};

[domenkozar]

Alright then let's make sure uv conflicts with poetry.

[lamalex]

I've started hacking around on a PR for this and from what I can tell this is blocked on uv 0.4.4 making it into packages. This PR astral-sh/uv#6834 added support for UV_PROJECT_ENVIRONMENT to actually have uv sync work with the venv in .devenv/state/venv.

To be honest, while looking at the source, this could use a fair bit of refactoring. Before I just dive in, is there a good place to discus what the actual behavior should be for the python language given the messiness of the ecosystem?

[lamalex]

My proposal:
venv, poetry and uv should all be mutually exclusive configuration blocks.
This would allow init-venv, init-poetry and init-uv to each make their own opinionated decisions best in line with their standards.

There's some useful bits which are shared across package management solutions

• python interpeter changes
• lock change detection (uv & poetry)

What would it take to make the change so that the package management configurations are mutually exclusive? Is there appetite for that, or is the current behaviour of venv configuration being shared actually desired?

[schlich]

i wouldn't go so far as to make them mutually exclusive in config. in monorepo setups you might have a submodule that uses a different package manager. there are a bunch of other weird possibilities, like using poetry for your main package manager but using uv to run scripts.

[Bullish-Design]

Just piping in to say how much I already enjoy using devenv, and to add another voice to say this would be an awesome improvement.

One question - would devenv be able to support UV managing the python installation itself?

[schlich]

Just piping in to say how much I already enjoy using devenv, and to add another voice to say this would be an awesome improvement.

One question - would devenv be able to support UV managing the python installation itself?

There's an interesting convo going on in the astral discord about dynamically linked binaries in NixOS as it relates to uv's installed binaries. From the NixOS docs: How to run non-nix executables?

NixOS cannot run dynamically linked executables intended for generic Linux environments out of the box. This is because, by design, it does not have a global library path, nor does it follow the Filesystem Hierarchy Standard (FHS).

There are a few ways to resolve this mismatch in environment expectations:
...

Write a Nix expression for the program to package it in your own configuration.
...
Build from source.
...
Modify the program’s ELF header to include paths to libraries using autoPatchelfHook.
...
Wrap the program to run in an FHS-like environment using buildFHSEnv.

This is a last resort, but sometimes necessary, for example if the program downloads and runs other executables.

Now, AFAICT this only applies to NixOS, i'm still learning about this issue/reasoning so i have no idea if it would be relevant to devenv given what I know, but just throwing it out there as a potential consideration.! I'll be curious to see what the astral team says about it. It's also possible the uv build command released today might address this? hmm

[clementpoiret]

Awesome if you are preparing something @lamalex, that would be a huge improvement for python dev w/ devenv! Please let us know if you have difficulties or if you need more hands!

Small question, the default devenv init initializes devenv.yaml with Cachix Rolling nixpkgs channel, which sounds outdated of few months. The default config always installs uv 0.1.x. Why not defaulting to nixpkgs 24.05?

[domenkozar]

See cachix/devenv-nixpkgs#2 (comment)

[schlich]

Any WIP on this? I'm going to start digging into the code @lamalex let's throw something up if we can avoid duplicating work