Switch from venv+pip to uv

[alexrudd2]

uv is to pip and venv what ruff is to pyflakes and black - faster and better in every way.

It greatly speeds up dependency resolution and install, and eliminates the fuss of activating venv on Windows (which I remember was quite fun to setup for @janiversen ... )

The dependency setup with a cache miss is <2s, which is nearly as fast as a cache hit with the existing solution.

[janiversen]

Looks like a nice change, but it seems uv is not ready to meet codespell.

[janiversen]

Feel free to exclude lock files in pyproject.toml.

[janiversen]

This change could be made a lot easier in ci.yml line 74 without any side effects.

[alexrudd2]

(1) No, since the call to sphinx-build is in build_html. It would fail without uv run (or activating the venv)
(2) By doing it this way it can work either with or without uv in either CI or locally.

I'm not ready to propose switching over the entire project yet. (e.g. python -m build -> uv build and some pyproject.toml changes)

[janiversen]

if you put uv in front of build_html it should activate the venv which will then be handed to sphinx.

Switching the whole project to uv, will not happen in a long time, since that would e.g. invalidate the use of work on to easily change environments.

[alexrudd2]

if you put uv in front of build_html it should activate the venv which will then be handed to sphinx.

You know I try things before writing you, right? :)

Switching the whole project to uv, will not happen in a long time, since that would e.g. invalidate the use of work on to easily change environments.

I'm not sure what exactly you mean here, but in my trials with uv it makes switching environments easier. It's not perfect but I added this to ~/.bashrc and it works pretty well:

# https://dev.to/moniquelive/auto-activate-and-deactivate-python-venv-using-zsh>
python_venv() {
  MYVENV=./.venv
  # when you cd into a folder that contains $MYVENV
  [[ -d $MYVENV ]] && source $MYVENV/bin/activate > /dev/null 2>&1 && uv sync ->
  # when you cd into a folder that doesn't
  [[ ! -d $MYVENV ]] && deactivate > /dev/null 2>&1
}

PROMPT_COMMAND="python_venv; $PROMPT_COMMAND"

[janiversen]

Yeah I expected you to try before writing, however if I run "workon" before calling build_html it uses the environment assigned, so I do not understand what the problem is with running "uv" before the build_html command. venv is normally inherited across shell sessions.

your python_env function have one floor, I have at the moment 8 different venv, and when I login to my vm, I start by "workon ".

[alexrudd2]

Interesting, this is my first hearing of workon.

For the CI, uv sync creates a venv, but does not activate it. So I had to activate it.

I think this is resolved to your satisfaction? build_html is untouched compared to dev.

[janiversen]

Thanks a lot, this seems to be a very GOOD solution.

I am sorry, that I had to "correct" you, your PR´s and comments are HIGHLY valued, but I also need to think of the consequences.

I am sure you will find an elegant solution for build_html as well.