Give the dockerfile some love (2/x) #94
Conversation
Exporting DEBIAN_FRONTEND via an `ENV` forces every invocation of the docker container to be 'noninteractive'. It's better to force the frontend as an `export` inside the shell every time apt-get is called.
There is no necessity to reduce a single layer's size in a docker image. What matters in a docker image is the overall size and the amount of layers.
Removes all the packages in the list, which are actually transient
packages of texlive-full.
texlive-full depends on:
texlive-fonts-recommended
texlive-fonts-extra
texlive-lang-english
texlive-lang-japanese
texlive-latex-extra-doc
texlive-pictures-doc
texlive-publishers-doc
latex-cjk-all
latex-cjk-chinese-arphic-bkai00mp
latex-cjk-chinese-arphic-gbsn00lp
latex-cjk-chinese-arphic-gkai00mp
The users should not change at all. So moving the layer to the bottom is the best choice.
bebehei
force-pushed
the
love4dockerfile
branch
2 times, most recently
from
eb72a09
to
51aa7d0
Compare
bebehei
force-pushed
the
love4dockerfile
branch
from
51aa7d0
to
8b018e4
Compare
| @@ -3,28 +3,23 @@ FROM ubuntu:18.04 | |||
| LABEL mantainer="Read the Docs <support@readthedocs.com>" | |||
| LABEL version="5.0.0rc1" | |||
|
|
|||
| ENV DEBIAN_FRONTEND noninteractive | |||
There was a problem hiding this comment.
I think this one is still needed for when you jump into the image and run apt install x directly, right?
There was a problem hiding this comment.
Yes, that's the reason why it's done via export ....
There was a problem hiding this comment.
I mean, running
docker run -it readthedocs/build:latest /bin/bash
I suppose that we still want to run with the noninteractive, don't we?
There was a problem hiding this comment.
Running it with docker run -i implies to be interactive, setting DEBIAN_FRONTEND=noninteracive is contradicting. 😉
See the official answer moby/moby#4032 (comment)
There was a problem hiding this comment.
Yeah, I know, but I want to have the same behavior when running apt install X from docker run -i than when that command is ran from Read the Docs build process internally (a os.system call at setup.py for example). Otherwise, it's hard to be sure that what I'm testing locally will work in production.
| ENV PATH /home/docs/.pyenv/shims:$PATH:/home/docs/.pyenv/bin | ||
| RUN curl -L https://github.com/pyenv/pyenv/archive/master.tar.gz \ | ||
| | tar xz \ | ||
| && mv pyenv-master .pyenv |
There was a problem hiding this comment.
I think it's better to keep the absolute path here (~docs/.pyenv) to avoid potential future problems.
There was a problem hiding this comment.
I'd rather use ~/.pyenv, ok? Specifying the docs user should be redundant.
|
Hi! Our Docker file has changed considerably since this PR was opened. We are now maintaining only the branches |
Takes care of #60