Skip to content
Advertisement

Optimizing the workflow for Python development using Docker+WSL2

I use different languages on a daily basis and hate it when my machine gets cluttered with many language specific installations/programs/environments. Therefore I’m currently exploring if using Docker+WSL2 as a runtime for my different projects suffices for keeping my host machine clean without too much overhead.

My current workflow at the example of Python:

  1. Create Python project on host machine
  2. Run Docker container based on the appropriate Python image and mount project directory into the container
  3. Create a virtual environment within the project directory and install required packages using bash in the container
  4. Run the project using bash in the container

This is the most simple way I found to keep my Docker images generic, i.e., without pre-installing project-specific packages in the Dockerfile. One drawback of this approach is of course that the virtual environment ends up on the host machine.

Others use docker commit which isn’t exactly best practice or install the required packages in the Dockerfile which leads to a giant Dockerfile for running all my Python projects.

Do you know a better workflow with less overhead or have ideas to mitigate the problem of the virtual environment folder?

Advertisement

Answer

You don’t need to keep your Docker image generic, one image is for one project in most cases. I would rather create a base image and push it to a registry, so you can have a quick build when you need to.

If you are using one image for all your project so your services can communicate, I strongly suggest the use of docker-compose configs.

Though on smaller Python projects I prefer conda environments, because they are light-weight and easy to set up / delete, plus there is https://conda-forge.org/ to get missing binaries through conda.

User contributions licensed under: CC BY-SA
6 People found this is helpful
Advertisement