[Distutils] Docker, development, buildout, virtualenv, local/global install

Jim Fulton jim at jimfulton.info
Wed Jun 15 07:53:59 EDT 2016

On Wed, Jun 15, 2016 at 5:07 AM, Reinout van Rees <reinout at vanrees.org> wrote:
> Hi,
> Buzzword bingo in the subject...
> Situation: I'm experimenting with docker, mostly in combination with
> buildout. But it also applies to pip/virtualenv.
> I build a docker container with a Dockerfile: install some .deb packages,
> add the current directory as /code/, run buildout (or pip), ready. Works
> fine.
> Now local development: it is normal to mount the current directory as
> /code/, so that now is overlayed over the originally-added-to-the-docker
> /code/.
> This means that anything done inside /code/ is effectively discarded in
> development. So a "bin/buildout" run has to be done again, because the bin/,
> parts/, eggs/ etc directories are gone.
> Same problem with a virtualenv. *Not* though when you run pip directly and
> let it install packages globally! Those are installed outside of /code in
> /usr/local/somewhere.
> A comment and a question:
> - Comment: "everybody" uses virtualenv, but be aware that it is apparently
> normal *not* to use virtualenv when building dockers.
> - Question: buildout, like virtualenv+pip, installs everything in the
> current directory. Would an option to install it globally instead make
> sense? I don't know if it is possible.

So, a number of comments.  I'm not going to address your points directly.

1. Creating production docker images works best when all you're doing
is installing a bunch of  binary artifacts (e.g. .debs, eggs, wheels).
If you actually build programs as part of image building, then your
image contains build tools, leading to image bloat and potentially
security problems as the development tools provide a greater attack
surface. You can uninstall the development tools after building, but
that does nothing to reduce the bloat -- it just increases it, and
increases buid time.

2. #1 is a shame, as it dilutes the simplicity of using docker. :(

3. IMO, you're better off separating development and image-building
workflows, with development feeding image building. Unfortunately,
AFAIK, there aren't standard docker workflows for this, although I
haven't been paying close attention to this lately.  There are
standard docker images for building system packages (debs, rpms), but,
for myself, part of the benefit of docker is not having to build
system packages anymore.   (Building system packages, especially
applications, for use in docker could be a lot easier than normal as
you could be a lot sloppier about the ways that packages are built,
thus simpler packaging files...)

4. I've tried to come up with good buildout-based workflows for
building docker images in the past.  One approach was to build in a
dev environment and then, when building the production images, using
eggs built in development, or built on a CI server.  At the time my
attempts were stymied by the fact that setuptools prefers source
distributions over eggs so if it saw the download cache, it would try
to build from source.  Looking back, I'm not sure why this wasn't
surmountable -- probably just lack of priority and attention at the

5. As far as setting up a build environment goes, just mounting a host
volume is simple and works well and even works with docker-machine.
It's a little icky to have linux build artifacts in my Mac
directories, but it's a minor annoyance.  (I've also created images
with ssh servers that I could log into and do development in.  Emacs
makes this easy for me and provides all the development capabilities I
normally use, so this setup works well for me, but probably doesn't
work for non-emacs users. :) )


Jim Fulton

More information about the Distutils-SIG mailing list