Use uv for package management

[JuroOravec]

After replacing flake8 with ruff, I was also thinking of updating other parts of the toolbelt. I was intrigued by uv, as it's popular right now.

Right now we use pip + requirements.txt files. We update these requirements.txt files in two ways:

• manually
• with pip-compile from pip-tools (not documented in your docs)

After looking into the documentation, it felt like it would bring a bit more overhead compared to maintaining just plain requirements.txt - for contributors who haven't used uv yet, you'll have to read up some more documentation to get started. After getting familiar with uv, it's about the same overhead as pip-compile.

But there are some clear benefits to uv too:

• Installation and virtual env setup should be 3-10x faster. We should install also tox-uv, so we can see the speedup in environments managed in tox, and thus in CI tests too. Based on the advertized speeds, CI test jobs could be overall 60% faster.

  

• Another thing I found useful is that uv supports monorepo structure with workspaces. I don't think we should migrate to workspaces right now, but it's nice to have a tool that can do so in the future.

TODO:

• [ ] Install uv
• [ ] Move the different environment dependencies (dev, docs, prod) from requirements.txt and requirements.in to uv
• [ ] Update documentation on development to talk about using uv for installing dependencies.
• [ ] Add section to development.md about how to update dependencies.
• [ ] Install tox-uv and configure tox to use it

[JuroOravec]

While we're at it, we could also move the current tox.ini inside pyproject.toml, so there's fewer config files lying around. See https://tox.wiki/en/stable/config.html.

(And unrelated, but maybe also remove .pre-commit-config.yaml? It doesn't seem to be used.)

[dalito]

I think even if .pre-commit-config.yaml is not used in CI it should be kept for local use by developers/contributors. The config just needs to stay compatible with other checks in CI. I prefer having the local immediate feedback from pre-commit over waiting for the slower CI. Tip: for pre-commit there is https://github.com/tox-dev/pre-commit-uv to make installation and venv creation much faster.

👍 on moving tox.ini to pyproject.toml

[JuroOravec]

Fair point. I don't use pre-commit personally (it feels too restrictive for me), so it's just that I can't tell if it's working or not.

I also use local checks a lot, it's just that I explicitly call tox with:

tox -e mypy,ruff

But I just noticed that pre-commit is already in requirements-dev.txt, I didn't thought that was the case. So I think right now it's a good compromise:

• pre-commit is among the dependencies when installing dev dependencies.
• But it's still opt-in. One has to run pre-commit install to activate it.

Altho, it might be good if the pre-commit hooks triggered the tox commands (just ruff and mypy checks). That way we'd ensure that indeed when one runs pre-commit, that it's the same command as what runs in the CI.

...

So I just tried that, and got it working with a config like so:

repos:
- repo: local
  hooks:
    # See https://stackoverflow.com/questions/70778806
    - id: tox
      name: tox
      entry: .venv/bin/tox
      args: ["-e", "mypy,ruff"]
      language: system
      pass_filenames: false

---

As for why I don't use pre-commit, I'm always afraid of using pre-commit (I used husky in the past), because I assume that it won't let me push to remote if there is an error. But sometimes, esp on larger PRs, I just need to push to save the changes, knowing that it will be broken.

Also I'm not a fan of when pre-commit hooks makes changes to the code (e.g. fix formatting). I want to know the exact code I'm pushing.