Official Docker containers?

[drewgingerich]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

I'm curious if official docker containers could be created (automated via Github actions).

Of course it's easy to install Poetry in a Dockerfile using get-poetry.py, but I see two issues:

1. Everyone has to write the boilerplate to install Poetry. Using an official container would remove this boilerplate.
2. get-poetry.py installs the latest version of Poetry and doesn't appear to have a flag for selecting the version. It's good practice for Docker containers have reproducible builds, and this instability in Poetry version prevents that. An official container could pin the Poetry version and allow for reproducible builds.

For context I'd like to use Poetry in a Docker container to export the requirments.txt, since it's error-prone and troublesome to manually keep that export up to date and it's redundant information when we have pyproject.toml and poetry.lock.

I'm actually surprised there are not already official Poetry Docker containers, so I'm wondering if this might be an intentional decision. On the other hand if this sound like a good idea, I can volunteer to work on a PR for it.

[n8sty]

For question 2, get-poetry.py takes a --version argument or you can use a POETRY_VERSION environment variable. I do the latter in Docker builds.

[drewgingerich]

That's great! I missed that, thank you.

So with that, while I think official containers would be convenient they wouldn't add much and I understand if this is low / no priority. Feel free to close this issue if it's not on the roadmap.

[n8sty]

This might be relevant for anyone who comes across this issue: #1879

[aucampia]

Are you open to PRs for this? I'm thinking of just adding another github actions workflow.

[aucampia]

The following approaches for doing this is available:

1. Create a repo for inclusion here: https://github.com/docker-library/official-images#docker-official-images (similar to https://github.com/docker-library/python)
2. Publish to docker.io independently of the official images process
3. Publish to ghcr.io

1 and 3 are probably the best options. If there is some support from this project for 1 then it may be a better option.

Some things to think about there should likely be tags for each latest version poetry for each of the supported and maintained pythons, for each variant of python (slim, alpine, standard).

[Pendragonek]

Hi, I have been working with Poetry in Docker for over a year now. Today I thought that it would be handy to have a official Docker image for Poetry and after some searching I stumbled into this issue. I am willing to work on this, but the catch here is that this will be my first contribution on GitHub. I will need some help, because I do not even know how to start properly and how the workflow looks like.

[adamwojt]

Bumping this. Would be awesome to have official images. Happy to contribute.

[lorantalas]

I forked the repo and currently working on docker images. I am using the same tools and structure as the python official image.
I'm not ready for publication yet. WIP

But my experiments raised some questions to be discussed:

1. Currently I have a poetry image for each python official image. Tags are the same. So each image contains only the last poetry version:

   poetry:3.8
   poetry:3.9-alpine3.15
   poetry:3.10-buster
   

   and so on

   This was mentioned by @aucampia:

   Some things to think about there should likely be tags for each latest version of poetry for each of the supported and maintained pythons, for each variant of python (slim, alpine, standard).

   It needs to be discussed if we are going to have just the last poetry version installed into each of the python images (like above).
   Or we'll have a range of poetry versions with the fixed version of python, like:

   poetry:1.1.13
   poetry:1.1.0
   poetry:1.1.1-alpine3.14
   

   and so on, with python 3.7 or above (TBD)

   Having both, the range of poetry versions for all python tags is too much IMO.

2. We need to choose one approach from the list provided by @aucampia above.

   Create a repo for inclusion here: docker-library/official-images#docker-official-images (similar to docker-library/python)
   Publish to docker.io independently of the official images process
   Publish to ghcr.io

   The first option requires a separate repository inside the organization.
   In the case of other approaches, we could do it here in the main repo.
   Maybe there is some need to have it in the separate repo in any case.

Maintainers and concerned parties, please advise, and let's discuss.

[tgolsson]

I don't really see the latter variant as consistently useful, neither as a maintainer of CI/CD nor as a user. Anyone serious about Docker images (in production) should be using shas, and that removes a lot of the need for saying "yesteryear's version". And as a user, I think more about what Python version I'm working with than the package manager version I'm using (which is never until it breaks). I do think there is value in pre-release/LTS/nightly style tags, but that's a much smaller set than "every poetry version".

Also: following the upstream pattern is awesome for discovery and migration. Having an "extension" image shoot of in an orthogonal direction makes switching harder...

- We're using Python 3.7 with alpine and want to start using Poetry
- Sure, you'll need to move to Python 3.9 and Debian but you can use any Poetry version
- 😕

compared to

- We're using Python 3.7 with alpine and want to start using Poetry
- Sure, just use poetry/poetry as the image name instead of python
- 🚀

For similar reasons; I'd argue for publishing from inside the the Poetry organization on GitHub to a Poetry organization on Docker Hub. It's easily discoverable; while still part of the Poetry maintainer's team ownership -- clear connection to community/maintainers and their needs/dev cycle. That also makes it easy to change publishing later; to anywhere, or even setup multiple publishing destinations -- or moving it into the Docker org if that makes sense later. So it's less committal while working out how this should work and what makes sense for Poetry.

[lorantalas]

@tgolsson

1. I agree that mirroring python tags is the better option, however, it never hurts to ask the community.
   I'll stick to mirroring, for now.

   I do think there is value in pre-release/LTS/nightly style tags, but that's a much smaller set than "every poetry version".

   Let's left it for later possible improvements.

2. We'll of course use the Poetry Org on GitHub for storing sources.
   My question was more about storing docker related stuff here in the main repo or in the newly created separate repo e.g. https://github.com/python-poetry/docker

   Where to push built images doesn't matter in terms of implementation. To make it "docker official" it's not required to move anything to Docker Org on Github.

   From my understanding we just need to follow some rules and submit information to the docker library like (from the official maven image):

   Maintainers: Carlos Sanchez <carlos@apache.org> (@carlossg)
   GitRepo: https://github.com/carlossg/docker-maven.git
   
   Tags: 3.8.5-jdk-11, 3.8-jdk-11, 3-jdk-11
   Architectures: amd64, arm64v8
   GitCommit: 925e49a1d0986070208e3c06a11c41f8f2cada82
   Directory: openjdk-11
   
   <omitted tags>	  
   

   In that case, the image would be available on https://hub.docker.com/_/poetry/ and could be referenced like: poetry:tag

   In case of publishing to Poetry Org on Docker Hub, we'll need to create an organization there.
   User with name poetry already exists . However, we may create user python-poetry to match the Github Org name. The image would be available on https://hub.docker.com/r/python-poetry/poetry and could be referenced like python-poetry/poetry:tag.

   I don't see any pros to using ghcr.io besides it's simple to implement. In the case of Github Packages, the image would be available on https://ghcr.io/python-poetry/poetry:tag and could be referenced like ghcr.io/python-poetry/poetry:tag (just more letters to type for end-users)

   Summary of "where to push" options:

   Registry	User	Repo URL	Reference
   hub.docker.com	docker-library	hub.docker.com/_/poetry/	poetry:tag
   hub.docker.com	poetry-org	hub.docker.com/r/python-poetry/poetry	python-poetry/poetry:tag
   ghcr.io	poetry-org	ghcr.io/python-poetry/poetry:tag	ghcr.io/python-poetry/poetry:tag

   We could decide where to push later on or change it anytime before releasing it to the public.

   If the separate repo is preferred by maintainers and Poetry Org, we could go this way.
   In my opinion, if we are going to try to make it "docker official" it's better to make a separate repository. Otherwise, it doesn't matter.

   For now, I will do my best to make clear code from my dirty experiments with docker-library tooling and submit a PR in this repo. No promises for sure, but I will try to contribute.

[lorantalas]

I submitted a draft PR with my code: #5491

The next step is CI/CD, so we need to decide where to push docker images.

[AGhost-7]

For now, would it be possible to have a "tutorial" section in the docs to show best practices such as disabling dependency caching, using --no-dev when installing, etc?

[mateusoliveira43]

Hi everyone,

I created repository aiming this purpose https://github.com/mateusoliveira43/docker-image-poetry I tried to follow the style of the Python Docker Image repository. The Image is already in Docker Hub https://hub.docker.com/r/mateusoliveira43/poetry (if you want a specific version of Poetry/Python that is not there yet, just open a issue there, and we can add it 😄)

I would be happy to help to create an official Poetry Image 😃

[jwsy]

Hi everyone,

I created repository aiming this purpose https://github.com/mateusoliveira43/docker-image-poetry I tried to follow the style of the Python Docker Image repository. The Image is already in Docker Hub https://hub.docker.com/r/mateusoliveira43/poetry (if you want a specific version of Poetry/Python that is not there yet, just open a issue there, and we can add it 😄)

I would be happy to help to create an official Poetry Image 😃

I did a scan with the latest grype and it came back with zero fixable vulns ✨
Awesome work @mateusoliveira43!! 🙌

$ grype version
Application:          grype
Version:              0.51.0
Syft Version:         v0.59.0
BuildDate:            2022-10-17T23:56:55Z
GitCommit:            4cda526992d5003dcbab68c9a7479a653dfde008
GitDescription:       v0.51.0
Platform:             darwin/amd64
GoVersion:            go1.18.7
Compiler:             gc
Supported DB Schema:  5

$ grype --only-fixed mateusoliveira43/poetry:1.2.2-python3.10.8-slim-bullseye
 ✔ Vulnerability DB        [no update available]
 ✔ Parsed image
 ✔ Cataloged packages      [152 packages]
 ✔ Scanned image           [84 vulnerabilities]
No vulnerabilities found

[thclark]

I feel like creating a base image with poetry installed will lead to a lot of discussions about what base image(s) to use, and create a horrible jam where anyone using their own or an unsupported base image will suffer, and the network of builds to support a mass variety of different images will lead to a level of complexity that the poetry team really shouldn't have to deal with.

What about, as an alternative, releasing an OCI devcontainer feature that allows addition of poetry to whatever base image we want (more info in this blog post)?

It's a pain point for me having to rewrite all my dockerfiles every time there's a bit of a shift here so I could probably justify allocating a day or two of my team's time to achieving this, but would want to see some buyin from the community and maintainers here first.

Whdjathink, folks?

[Secrus]

@thclark we already have a PR for Dev Containers implementation

[thclark]

Perfect, thanks @Secrus. I'd assumed that would straightforwardly solve the issue but now am not sure whether it's even possible to reuse those features in a production build. If it's possible, surely that'd solve our problem here, so I asked an SO question](https://stackoverflow.com/questions/76365548/is-it-possible-to-install-devcontainer-features-in-production-container-builds)

[faemmi]

@thclark I took a look at your repo and I have a suggestion for you, because I've also built my own poetry image: you can use Docker args to reduce everything to a single Dockerfile.

ARG PYTHON_DOCKER_IMAGE
ARG POETRY_VERSION

# Use build layer
FROM python:${PYTHON_DOCKER_IMAGE} as builder

ARG PYTHON_DOCKER_IMAGE
ARG POETRY_VERSION

ENV POETRY_HOME=/opt/poetry

RUN echo PYTHON_DOCKER_IMAGE=${PYTHON_DOCKER_IMAGE} POETRY_VERSION=${POETRY_VERSION} 

RUN if [ -z "${PYTHON_DOCKER_IMAGE##*alpine*}" ]; then \
        echo "Installing required packages for alpine image"; \
        apk update; \
        apk add gcc musl-dev python3-dev libffi-dev openssl-dev cargo; \
    else \
        echo "Skipping installation of required packages for alpine image"; \
    fi

# Install poetry
ADD get-poetry.py /opt/get-poetry.py
RUN pip3 install --no-cache-dir --upgrade pip 
RUN python /opt/get-poetry.py --version ${POETRY_VERSION}

# Use runtime layer
FROM python:${PYTHON_DOCKER_IMAGE}

# Disable creation of virtual environments to reduce image size
ENV POETRY_VIRTUALENVS_CREATE=false \
    POETRY_HOME=/opt/poetry \
    PYTHONFAULTHANDLER=1 \
    PYTHONUNBUFFERED=1 \
    PYTHONHASHSEED=random \
    PIP_NO_CACHE_DIR=off \
    PIP_DISABLE_PIP_VERSION_CHECK=on 

# Copy poetry into image
COPY --from=builder /opt/poetry /opt/poetry
ENV PATH="${POETRY_HOME}/bin:${PATH}"

RUN pip3 install --no-cache-dir --upgrade pip 

CMD ["python3"]

I have the get-poetry.py in my repo and copy it into the image at build time rather than downloading it due to safety reasons.

And then you can do

export POETRY_VERSION=1.7.1
export PYTHON_VERSION=3.12
export PYTHON_DOCKER_IMAGE_TYPE=alpine
export IMAGE_NAME=poetry-${POETRY_VERSION}-${PYTHON_VERSION}
docker build \
  --build-arg PYTHON_DOCKER_IMAGE=${PYTHON_VERSION}${PYTHON_DOCKER_IMAGE_TYPE:+-$PYTHON_DOCKER_IMAGE_TYPE} \
  --build-arg POETRY_VERSION=${POETRY_VERSION} \
  -f Dockerfile \
  -t ${IMAGE_NAME} \
  .

I have slightly adjusted the commands here, so no guarantee it works out of the box.

You can very nicely use this in CI/CD to deploy multiple Docker images for every Python version you desire if there is a new poetry release. I takes me less than a minute to roll out a new set of Docker images if there is a release.

[thclark]

That's very nice, thanks @faemmi