Thanks to visit codestin.com
Credit goes to github.com

Skip to content

ENH: add build arg to control Python base #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 11, 2020

Conversation

tacaswell
Copy link
Member

This will let us control with version of the Python image we build on top of.

Dockerfile Outdated
Comment on lines 1 to 2
ARG BASE=3.8
FROM python:$BASE
Copy link
Contributor

Choose a reason for hiding this comment

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

@tacaswell looks good. I'm used to just having the image with tag as the whole build arg, but I think this will work but I will check and then confirm.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, this works. My default is

ARG BUILDER_IMAGE=python:3.8
FROM ${BUILDER_IMAGE} as builder

to just make things very explicit (the builder stuff is just because I almost always use multistage builds but probably not needed here now). But I have confirmed that

docker build . \
       -f Dockerfile \
       --build-arg BASE=3.8 \
       --tag matplotlib/mpl-docker:debug-3.8

works.

Copy link
Member Author

Choose a reason for hiding this comment

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

That makes sense.

Copy link
Contributor

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

@tacaswell Added some suggestions but this will work.

Dockerfile Outdated
Comment on lines 1 to 2
ARG BASE=3.8
FROM python:$BASE
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, this works. My default is

ARG BUILDER_IMAGE=python:3.8
FROM ${BUILDER_IMAGE} as builder

to just make things very explicit (the builder stuff is just because I almost always use multistage builds but probably not needed here now). But I have confirmed that

docker build . \
       -f Dockerfile \
       --build-arg BASE=3.8 \
       --tag matplotlib/mpl-docker:debug-3.8

works.

Dockerfile Outdated
@@ -1,4 +1,5 @@
FROM python:3.7
ARG BASE=3.8
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
ARG BASE=3.8
ARG BASE=3.8-slim

Might try using the slim image to bring down the size?

Copy link
Contributor

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

LGTM

@tacaswell tacaswell merged commit c833d89 into matplotlib:master Jul 11, 2020
@tacaswell tacaswell deleted the add_base branch July 11, 2020 19:36
@QuLogic
Copy link
Member

QuLogic commented Jul 11, 2020

I did not use -slim because it's preferred to not use it https://hub.docker.com/_/python

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run python. Unless you are working in an environment where only the python image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

@tacaswell
Copy link
Member Author

whoops, Matplotlib does not build in this image any more, will put that back in #8

@matthewfeickert
Copy link
Contributor

@QuLogic Ah sorry. My bad.

@matthewfeickert
Copy link
Contributor

@QuLogic If it is of interest, I can later do a comparison study of how much space can be saved if the relevant packages are added in as compared to using the full image. This is what I have done in other images to shave off tens of MB here and there, but I'm not sure how much of interest that is here.

@QuLogic
Copy link
Member

QuLogic commented Jul 11, 2020

I'm fairly certain it's smaller (but I don't remember by how much), but I don't really know that we decided what our target is, i.e., a single CI/developer system or a CI/developer with shared existing images.

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.

3 participants