I feel like it's this simple:

❯ docker volume ls
DRIVER    VOLUME NAME
❯ docker run \
    --rm \
    --volume .:/app \
    --volume /app/.venv \
    --publish 8000:8000 \
    -it \
    $(docker build -q .) \
    uv sync
Resolved 28 packages in 0.97ms
Audited 27 packages in 0.12ms

Here I run the container with a bind mount and anonymous volume and run uv sync. Note there's nothing to do — all of the requirements are in the directory from the image build.

Similarly, you can see .venv is not empty.

❯ docker run \
    --rm \
    --volume .:/app \
    --volume /app/.venv \
    --publish 8000:8000 \
    -it \
    $(docker build -q .) \
    ls -lah .venv
total 24K
drwxr-xr-x  4 root root 4.0K Aug 28 13:48 .
drwxr-xr-x 14 root root  448 Aug 28 13:45 ..
-rw-r--r--  1 root root    1 Aug 27 01:46 .gitignore
-rw-r--r--  1 root root   43 Aug 27 01:46 CACHEDIR.TAG
drwxr-xr-x  2 root root 4.0K Aug 28 13:48 bin
drwxr-xr-x  3 root root 4.0K Aug 28 13:48 lib
lrwxrwxrwx  1 root root    3 Aug 27 01:46 lib64 -> lib
-rw-r--r--  1 root root  137 Aug 27 01:46 pyvenv.cfg

run the container with volumes attached, without rebuilding it, check the state of .venv directory. If uv command was run before you can access the container, you'll see .venv with updated requirements. If it didn't run, .venv directory will be empty.

If you don't rebuild the image, it won't reflect pyproject.toml changes in the environment until you run a uv command in it. That's the whole point — the virtual environment isn't mounted from the host to the container.

Configurable project virtual environment paths (e.g., for Docker) #6669

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions