Request: Official uv devcontainer

[rdong8]

Would be really cool if we could get an official uv devcontainer for remote development using common IDEs (VS Code, PyCharm). It isn't too difficult to install uv in the Dockerfile by hand but an official option would be great. Currently the Python devcontainers are published version-by-version, so we don't have access to 3.13 yet.

[wstrausser]

Agreed that this would be great to have. For now, I've just been using the following Dockerfile for uv-based devcontainers:

FROM mcr.microsoft.com/devcontainers/base:bullseye

USER vscode
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

[ryanhiebert]

If you want to avoid a custom dockerfile, you might be able to use this feature from the devcontainer.json. It's been working pretty well for me.

{
    "features": {
        "ghcr.io/va-h/devcontainers-features/uv:1": {}
    }
}

[tobiasdiez]

At https://github.com/tobiasdiez/sage/tree/fedora-devcontainer-meson/.devcontainer/uv a working devcontainer feature for uv can be found. If someone wants to continue working on this, please feel free to use it as a starting point. (Essentially only publishing it to the ghcr repository is missing)

[FidelusAleksander]

Looks like it was added to the devcontainers-extra repository recently (September 2025)

https://github.com/devcontainers-extra/features/tree/main/src/uv

[coretl]

Another alternative (for those that find features make the devcontainer build too slow), we added uv (and other build tools) to a base ubuntu container, then use uv to manage the python version, and publish in step with upstream ubuntu:
https://github.com/DiamondLightSource/ubuntu-devcontainer

[dunnkers]

There's also https://github.com/dunnkers/python-uv-devcontainer

Disclaimer: I created that repo. It's using a Devcontainer Features so there's little extra install scripts necessary to get it to work.

[ryan-minato]

Support this request +1. However, we need to address a major blocker: broken symlinks in .venv when container restarts.

In Dev Container environments, uv defaults to symlinking the Python interpreter. Since the container's root filesystem is often ephemeral while the workspace is persisted, these links break upon restart. Even with UV_LINK_MODE=copy, the interpreter remains a symlink, forcing uv to delete and full environment re-installation.

This is a huge issue for ML projects (which need pytorch, flash-attention) where re-installation is slow. I've detailed this in #17754 .

[ryan-minato]

An Image or Feature alone cannot fix this, as volume mounting is managed by devcontainer.json. My current workaround is to manually mount a volume for ~/.cache/uv and use a postCreateCommand to fix ownership, but this is not a sustainable solution.