Reduce size of python image

[blueyed]

I would suggest using ncdu / in the image to show candidates for purging.

E.g.:

/usr/share/doc: 82.3MiB
/usr/share/locale: 63.5MiB

A concrete example for purging would be /usr/share/doc/gcc-4.9-base/test-summaries.

Maybe localepurge could be used to only ship English locales in the default image?

Ref: #30 #37

[yosifkit]

Have you looked at slim? The slim versions are designed for those that want to minimize their footprint (docs), but they will need to install any system libraries.

As far as reducing the buildpack-deps image size, it could possibly be accomplished, but I think purging the non-english locales would be presumptuous.

[dsikes]

Hi @yosifkit,

I looked at the slim image and noticed that you are pulling in all of the make utilities and building python from source, which makes this image HUGE. Wouldn't it make sense to just include the pre-built binaries, and not including all of the make utilities? I know it would drastically reduce the size of the image. Having the build service included in the docker image seems a bit overkill to me.

Maybe people wouldn't have to be presumptuous and try and remove 63 MB of non-English locales if the "reduced footprint" of the slim image wasn't contrived from a dockerfile that builds from source and then is released on the registry with all of the make/gcc/build utils still installed, sucking up additional space.. You guys should have your own internal dockerfile that builds from source, and then a released official image that includes something lightweight like wheezy or even jessie bare, with nothing but the pre-built binaries... IMO just a pure python container shouldn't be more than 150 MB... Who wants the footprint of any sort of build utils on an official image that is meant to just merely run an application.. it goes against the paradigm of containerization... 1 container to just do 1 thing and 1 thing really well... running a python app is the one thing.. not building python from source and then running the python app on the same server... Just My Opinion...

[yosifkit]

@dsikes and @appcontainers, none of those build packages are kept in the final image: slim/Dockerfile#L55. The only things kept are: ca-certs, libsqlite3, and libssl (slim/Dockerfile#L11-13).

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
python              3.4.3               2916985fe29a        3 days ago          683.3 MB
python              3.4.3-slim          721d6f4d1230        3 days ago          215.2 MB
debian              jessie                9a61b6b1315e        3 days ago          125.2 MB

I would welcome a PR making a smaller python based on debian:jessie using the upstream recommended install method (ie from source for unix/linux: https://www.python.org/downloads/release/python-343/)

[macropin]

While you're at it how about removing the wheel package. There is no point to caching wheels in a Docker image.

[tianon]

Is this issue still relevant now that we have both a slim and a supertiny alpine variant?

$ docker images python
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
python              3-alpine            956bddfd0b6c        3 days ago          89.42 MB
python              3-slim              c22a44a1fc6c        9 days ago          218.4 MB
python              3                   af91e46ec581        9 days ago          689.1 MB

[blueyed]

I think that it improved enough to close this issue.

Thanks!

[Gladskih]

1.01 GB?! There is something deeply wrong with the default "official" image.

[tianon]

1.01 GB?! There is something deeply wrong with the default "official" image.

Do you have some constructive feedback to share, or are you just here to complain/abuse? While I appreciate your edit that clarifies which thing you're complaining about, your tone is inappropriate for this forum. Please be more mindful of the humans on the other end of your comments in the future.

In the spirit of good faith, I will direct you to the "Image Variants" section of https://hub.docker.com/_/python which notes/describes this in more detail -- every choice we make in this regard is a tradeoff between various aspects of usability, security, size, etc, and we're sorry that the tradeoffs we have chosen do not meet your needs, but it is pretty disingenuous to discount our attempts to do so in the "non-default" variants (slim, alpine), and the amount of work that goes into maintaining them.

This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages.

(latest and friends)

vs

This image does not contain the common Debian packages contained in the default tag and only contains the minimal Debian packages needed to run python.

(slim)

vs

This variant is useful when final image size being as small as possible is your primary concern.

(alpine)

[Gladskih]

Of course I have switched to alpine immediately. But I am sure that most of people will just use the most default thing which runs somehow. And it means that a lot of automations over the world will be inefficient or avoid usage of the image (based on the first impression). That's why I believe default should be tiniest.

As to

your tone is inappropriate for this forum

I would just respond with the same statement. Be mindful in your accusations.