Best practices on building a Python Development Environment


We are using Alpine to build our runtime images and since it is very minimal we cannot vscode there (no scp).

I hav tried to simply use the official python image (python:3.10), but that would mean we need to bootstrap the following:

  1. Installation of poetry (since we use it for dependency management)
  2. Installation of packages (probably with dev as well)
  3. Installation of vscode extensions

Regarding #1, we can simply add poetry to dev image and use it instead of the official one
Regarding #2, #3, it would be great to get you opinion on the matter and see what is considered a best practice in this scenario

Thank you :slight_smile:

Super interesting question @idogdeveleap !

What I’ve seen work really well is to create a base image with all the tools that your team will need (python, poetry, vscode extensions), and then you can create a per-project dev image that has all the dependencies that every specific project needs.

For the “base dev image” that I talked about, you can use our python dev image as inspiration. This is an image that you build once, and that everyone uses as a base for the per-project images. I would put this on CI, and build it on demand whenever you want to upgrade core experiences.

The per-project image will be tightly coupled to your project. This is where you install dependencies. I prefer to build this as part of the Okteto pipeline so that my team always gets the latest dependencies.

Your project configuration files would look something like this (since it’s a sample, I’m not optimizing the image for size)

# Dockerfile
FROM  company/your-base-dev-image as dev

# copy dependencies
COPY poetry.lock pyproject.toml /usr/src/app
RUN  poetry install --no-interaction --no-ansi

# copy the rest of the code
COPY . . 

CMD python
# okteto.yml
    context: .
  - helm upgrade --install app chart --set image=${OKTETO_BUILD_API_IMAGE}
    command: ["bash"]
      - 8080:8080
      - .:/usr/src/app

Once this works, you should explore targeting build stages to have a dev and a prod stage of every Dockerfile, and then use the dev stage on your dev configuration. This is a more advanced pattern, so I’d recommend you start with my suggestion above first. You can see this advanced pattern in action on our movies demo repository.

That’s a great example. I’ve already got some ideas to things I would like to have in my dev img

Thank you so much for this!!!

1 Like