Skip to content

Conversation

@stefanv
Copy link
Contributor

@stefanv stefanv commented Oct 12, 2021

@mattip
Copy link
Contributor

mattip commented Oct 12, 2021

Is using a single RUN command instead of breaking each command into a separate RUN the recommended way to structure a Dockerfile? I would think separate commands give a more layered approach to running the docker build.

&& rm -f get-pip.py \
&& rm -rf ~/.cache

CMD ["/bin/bash"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to have something like this to choose the proper python image (taken from the other docker files)

# Run Python selection on way into image
COPY choose_python.sh /usr/bin/
ENTRYPOINT ["/usr/bin/choose_python.sh"]
``

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now fixed.

&& apk del --no-network .fetch-deps \
&& apk del --no-network .build-deps

ENV PIP_ROOT_URL="https://bootstrap.pypa.io"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you prefer using get-pip over using ensurepip?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what is being used in the other images, and also in the official Python docker images. But I have no preference, personally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now switched over to ensurepip.

Copy link

@adeak adeak Oct 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

README.md says

Pip installed for each Python via get-pip.py.

Does this also need updating?

Update: probably not, as this is just for alpine.

@stefanv
Copy link
Contributor Author

stefanv commented Oct 12, 2021

Is using a single RUN command instead of breaking each command into a separate RUN the recommended way to structure a Dockerfile? I would think separate commands give a more layered approach to running the docker build.

Yes, this is purposeful. It turns out that adding layers is very costly in terms of image size, and the best way to keep them small is to combine commands.

Also configure /usr/bin/python to link to a version of Python that can
run virtualenv, install virtualenv, and link it to where choose_python
expects it to be.
@matthew-brett
Copy link
Contributor

Nice - thanks for doing this ...

@matthew-brett
Copy link
Contributor

Test failure looks unrelated? Does this need a Travis-CI entry?

@stefanv
Copy link
Contributor Author

stefanv commented Oct 12, 2021

I added a matrix entry for Alpine.

@mattip
Copy link
Contributor

mattip commented Oct 13, 2021

Cool, thanks. Is there a way to confirm that the container is usable in multi-build/multibuild#430 (note that the repo has moved)

@matthew-brett
Copy link
Contributor

I guess the trick would be to put the image up somewhere, so we could use it to test against the PR ...

@mattip mattip merged commit f89818f into multi-build:focal Oct 13, 2021
@mattip
Copy link
Contributor

mattip commented Oct 13, 2021

Probably the easiest way to do that is to merge this, so in it goes.

@mattip
Copy link
Contributor

mattip commented Oct 13, 2021

The docker image is up https://hub.docker.com/u/multibuild. It is called "focal_alpine", maybe it should be alpine_x86_64 like the focal_x86_64 one. Is there a chance we will see an alpine_arm64v8 or alpine_i686 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants