On Wed, Jun 15, 2016 at 5:07 AM, Reinout van Rees <rein...@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 time. 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 -- Jim Fulton http://jimfulton.info _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
