Introduce uv for Python dependencies management

[David-Guillot]

Closes #141

The main benefits of uv for this project are:

• (Much) Faster build
• Better readability of dependencies: only top-level deps are listed in pyproject.toml

[mbeijen]

Hi David, I wanted to start a new django project this weekend, and found your PR and thought I'd base my project on Lithium, using your work because I ❤️ uv.

However I found a problem when I follow the instructions in your README after I configured PostgreSQL as per the instructions and when I run docker compose exec web python manage.py migrate. I'm not sure why, I see psycopg-binary in uv.lock.

$ docker compose exec web python manage.py migrate
Traceback (most recent call last):
  File "/app/.venv/lib/python3.12/site-packages/django/db/backends/postgresql/base.py", line 25, in <module>
    import psycopg as Database
  File "/app/.venv/lib/python3.12/site-packages/psycopg/__init__.py", line 9, in <module>
    from . import pq  # noqa: F401 import early to stabilize side effects
    ^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/psycopg/pq/__init__.py", line 117, in <module>
    import_from_libpq()
  File "/app/.venv/lib/python3.12/site-packages/psycopg/pq/__init__.py", line 109, in import_from_libpq
    raise ImportError(
ImportError: no pq wrapper available.
Attempts made:
- couldn't import psycopg 'c' implementation: No module named 'psycopg_c'
- couldn't import psycopg 'binary' implementation: No module named 'psycopg_binary'
- couldn't import psycopg 'python' implementation: libpq library not found
<snip>
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 or psycopg module

I managed to work around it by installing libpq in the Docker container, like so:

--- a/Dockerfile
+++ b/Dockerfile
@@ -13,7 +13,7 @@ RUN --mount=type=cache,target=/root/.cache/uv \
 
 # Then, use a final image without uv
 FROM python:3.12-slim-bookworm

+RUN apt-get update && apt-get install -y libpq-dev

[David-Guillot]

Ah yes you're right @mbeijen , thanks! Your added line is correct, but not at the right place: it must be inserted before RUN uv sync --no-dev ; I'll change that in the next few minutes.

[David-Guillot]

There you go @mbeijen . It took me a bit more time than expected as I tried making psycopg[c] and psycopg[binary] coexist but I couldn't manage it, so I'm backing off to psycopg[binary] everywhere, which is what we get on branch main anyway. I'll address that in a future PR when this one will be merged.

[jefftriplett]

Any reason to not include uv in our final image? It seems useful.

[David-Guillot]

Two reasons yes:

1. I think it's a best practice in most cases to avoid getting build tools in production. Your production code doesn't need it:

• Dependencies have already been resolved and installed (that's the build step)
• There is no multiple-Python or multiple-venv shenanigans within the container

2. The official guide for using uv with Docker provided a ready-to-go multistage Dockerfile, so it seems not only they agree with 1., but also they make it trivial to implement.

Some figures:

• python:3.12-slim-bookworm is 124MB
• ghcr.io/astral-sh/uv:python3.12-bookworm-slim is 157MB

@jefftriplett do you think there are use cases for having uv in the container?

[jefftriplett]

It's all trade-offs, and I think that's fine.

It might be something to re-think (maybe add a production layer) once we merge requirements.in into pyproject.toml. That makes having dev requirements easier. (after this PR merges)

I kind of view these projects as more dx/dev-friendly so being inside compose should expose uv so we can run uv lock or uv add {package} but I'm honestly still new to the Lithium.

All good and thank you for the explanation.

[jefftriplett]

There you go @mbeijen . It took me a bit more time than expected as I tried making psycopg[c] and psycopg[binary] coexist but I couldn't manage it, so I'm backing off to psycopg[binary] everywhere, which is what we get on branch main anyway. I'll address that in a future PR when this one will be merged.

psycopg[binary] is what I would have done too.