#2822 Add dockerfile install instructions

[Saphyel]

Pull Request Check List

Resolves: #2822

Ideally if the poetry team can provide an official poetry.Dockerfile that would be amazing, I'd be happy to help/maintining/looking after so people can only need to implement the project.Dockerfile file.

it's also possible to do it in one file combining the commands if you do not care too much about the best practices in docker.

I'm happy to push or accept any changes on my commit/s

[abn]

Why is all this required? Shouldn't this just be pip install poetry?

[Saphyel]

What if I change the whole thing to:

Suggested change

	poetry.Dockerfile
	This is not officially supported yet. Use your container/image as a virtual machine and install it using any way mentioned here and we recommend that you still use virtualenvs.

[abn]

This is not something we recommend at all.

[abn]

One of the reasons why we have yet to officially provide a "poetry contianer" is that poetry can be installed in container environments using pip install poetry and this is what should be done. This is because the official installer is not required here as within a container multiple python versions are not expected. And the poetry install step is usually cached anyway. So maintaining an official container does not really make much sense since, in order to be useful you would have to provide versions for every python base containers. Additionally, even in a container environment, you are better off using a virtual environment unless it is explicitly not required - eg: using system packages etc.

What we might do later, is a provide a repository with container usage patterns for various use cases and build scenarios.

[Saphyel]

The problem I see using pip install poetry is you will install some dependencies in your container that you may not need for your project or can be a conflict with your project.
In this way you are importing a folder.
I'm not sure why require to use virtual environment when that's the whole point of having containers.

Probably if you can explain why someone would go to the hassle of update the version of the interpreter when I could update the virtual environment? or in this case in the other way around why use the virtual environment when I could use directly the interpreter that I want?

[br3ndonland]

#3209 (comment)

maintaining an official container does not really make much sense

@abn I agree. There's no need for the Poetry team to maintain a Docker container image. The official Python image is adequate.

What we might do later, is a provide a repository with container usage patterns for various use cases and build scenarios.

This would be nice to have. I work with Poetry in Docker frequently, and I'm happy to help with this in the future. I would suggest closing this PR, and providing info on Docker use cases outside of the core docs.

#3209 (comment)

The problem I see using pip install poetry is you will install some dependencies in your container that you may not need for your project or can be a conflict with your project.

I've never seen dependency conflicts arise in this situation. I would guess it's quite rare, but I would welcome a reproducible example of Docker dependency conflicts.

I'm not sure why require to use virtual environment when that's the whole point of having containers.

@Saphyel if you're looking for a Docker configuration that might suit your preferences, I would suggest the following:

FROM python:3.8
ENV POETRY_HOME=/opt/poetry POETRY_VIRTUALENVS_CREATE=false PYTHONPATH=/app
COPY poetry.lock pyproject.toml /app/
WORKDIR /app/
RUN curl -fsS -o get-poetry.py https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py && \
  python get-poetry.py -y && . $POETRY_HOME/env && \
  poetry install --no-dev --no-interaction --no-root
COPY mypackage /app/mypackage
CMD python /app/mypackage/main.py

[abn]

Regarding dependency conflicts; there are a few things to note here.

1. Usage patterns cannot assume that the base container is docker.io/python:* as a lot of use cases use distro base images and construct "supported" python instances. There is no guarentee that the python site is going to be clean. A particularly annoying example is that of the ubuntu base image (this might be resolved in newer base images) using custom distutil and virtualenv hacks.
2. While the python base images are typically up-to-date, and site is empty except for setuptools, pip and wheel (expected virutalenv packages), this might not always be guareteed.
3. At the moment, poetry is only essentially tested on the versions of pip, setuptools and wheel bundled with whatever version requirement poetry specifies for virtualenv. We have had issues with pip versions in system installed pythons. For example; python -m ensurepip will not install the latest version of pip but rather the version that is paired with that python version.

Putting all that together, recommending not using a virtual environment is not necesarily the best idea. And unfortunately, there has been bugs in the issue history if you dig that have been caused due to this. All that said, I am not necesarily saying it is "wrong", but that it just shouldn't be the recommended pattern.

[9mido]

I am really confused here.

https://python-poetry.org/docs/#installing-with-pip

The poetry docs state that "Be aware that it will also install Poetry's dependencies which might cause conflicts with other packages." is on par with what @Saphyel said.

But the opposite is being recommended in this discussion.

Then what is the recommended way @abn ? Can we see an example?

Should we use the method @br3ndonland recommended or something else like in issues #856 or #1879 recommends?

[Saphyel]

@9mido I think they are recommending using virtualenv inside of docker, I know is sort of defeating the whole purpose of using containers and having an even bigger image.

So, my recommendation is if you have a cloud based project the recommendation is use pip, poetry, as being probed here, it is not ready yet.

[br3ndonland]

I am really confused here.

@9mido you're not alone in your confusion. There's a GitHub Discussion topic on this now (#1879), so I posted a comment there. Hope it helps.

[robertlagrant]

I think they are recommending using virtualenv inside of docker, I know is sort of defeating the whole purpose of using containers

I don't think this defeats the whole purpose of using containers at all. Containers provide sealed, standardised deployment units. Using virtual environments in them will still do that.

[neersighted]

I think they are recommending using virtualenv inside of docker, I know is sort of defeating the whole purpose of using containers

I don't think this defeats the whole purpose of using containers at all. Containers provide sealed, standardised deployment units. Using virtual environments in them will still do that.

I have to agree with @robertlagrant here -- that is what is being said. Containers do not eliminate the desire to keep your app's dependencies separate from Poetry. While you could subvert Poetry by installing it into a virtualenv in your Dockerfile and then having Poetry install app dependencies into the global site-packages, inverting the standard paradigm like that serves no real functional purpose. You would merely be venturing into unexplored territory out of aesthetic reasons.

Anyway, this suggestion is the real takeaway here:

What we might do later, is a provide a repository with container usage patterns for various use cases and build scenarios.

Any work to provide such a resource would be appreciated. It could be officially promoted/supported by the Poetry team, or remain a standalone resource with 'community' status in the docs.

I'm going to close this PR for now, but please do use it as a base for the above repo/resource.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.