Questions about dev containers

Avatar
Julian Herbst97
Created

Hi all,

I have recently started a new project and configured myself an interpreter using a dev container. I have the docker-compose.yml and the devcontainer.dockerfile all set up, I just have a few questions:

 

  1.  I pass my project directory to the container through the docker-compose, because my program needs to access some config files, and also some PDF templates that it fills with data and then stores back on the host machine for me to look at. Is that the right way to do it, or are there better methods
  2. When I click run, it creates a container, runs the code, then exits the container as expected, and it always says devcontainer-1. However, in the PyCharm services pane under docker, I see a bunch of ghost containers called devcontainer-23456235 and stuff like that, that I don't see when I do 'docker ps -a' or 'docker container ls -a' or something like that in the command line. Are those really there taking up space, or are hey just somehow artefacts of PyCharm that go away on their own eventually?
  3. How do I force the docker-compose to rebuild the container when I add something to the pyprojects.toml? If I add numpy via 'uv add numpy' in the "regular" host machine command line, and then write a function that imports and uses numpy, when I run it through the container interpreter I get an error with "no package called numpy" because I guess it didn't see that the requirements.txt changed. Is there a way to fix that so that for example the dockerfile or docker-compose says it should run 'uv sync' on startup?
  4. What is the difference between configuring an interpreter through docker-compose, vs opening a dev container through the services pane? It seems to want a devcontainer.json which I don't really know what it wants me to write in there.

Thanks in advance for answering!

Votes

0

Share

1 comment
Avatar
Mikhail Tarabrikov
Created

Hi Julian Herbst97 

1. Passing the project directory through docker-compose volumes

Yes, that's the right way to do it. The Docker Compose interpreter expects your project to be mounted inside the container, and a bind mount in the volumes: section is how that's normally done. Reading config files from the mount and writing the filled PDFs back to the host through it is a normal use of bind mounts, so no need to change anything there. The setup is described in https://www.jetbrains.com/help/pycharm/using-docker-compose-as-a-remote-interpreter.html.

2. The "ghost" devcontainer-NNNN containers in the Services pane

Trust docker ps -a here: those entries aren't real containers and take up no space. PyCharm starts short-lived helper containers for indexing and interpreter introspection, and there's a known display bug where stale entries for them stay in the Services view even though Docker already removed them. They can't be deleted from the IDE and they disappear after a restart. This is tracked as PY-78640. You can vote for it and follow updates there, see this article on how watching YouTrack issues works.

3. Getting new dependencies into the container after uv add

This part is expected behavior rather than a bug. With a compose-based interpreter, the packages live in the image, and PyCharm doesn't rebuild it when pyproject.toml changes. The simple approach is to rebuild the service after dependency changes, then re-run:

docker compose build <your-service>

Also worth knowing: PyCharm 2026.1 added a proper uv interpreter type for Docker and Docker Compose (PY-84075), which makes PyCharm understand uv-managed environments inside containers much better (package listing and management used to fail for them). If you're on an older version, updating to 2026.1 is worth it for this workflow.

4. Docker Compose interpreter vs. dev containers in the Services pane

These are two different features. With a Docker Compose interpreter, PyCharm itself runs locally and the container is only the Python runtime: PyCharm starts the service to run or debug your code and stops it afterwards, which matches what you described. Dev Containers (the thing asking for devcontainer.json) is full remote development: the IDE backend runs inside the container and your local window becomes a thin client to it. devcontainer.json is a file from the open Dev Containers specification that describes the whole environment, an image or a compose service plus lifecycle hooks such as postCreateCommand (another place where uv sync could live in that model).

Since you mainly want your code to run in the container while you work in a local IDE, the compose interpreter you already have is the simpler fit. Dev containers become interesting when you want the entire development environment, including the IDE tooling, to live inside the container.

If something still doesn't behave as described, let us know your PyCharm version (Help | About) and we'll take a closer look.

0

Please sign in to leave a comment.