On Wed, Jun 15, 2016 at 12:07 PM, Reinout van Rees <reinout@vanrees.org> wrote:
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.

Think of it like this: if you don't mount ./ as /code in the container then you practically have to rebuild the image​ all the time. This is fine for toy projects, but bigger ones have lots of files (eg: templates, images, css, tons of js 1-line modules etc). That means you get a big context that is slow to send (exacerbated in situations that have remote docker daemons like osx/windows docker clients).

​Another compound problem: if you rebuild the image for every code change the new context will invalidate the docker image cache - everything will be slow, all the time. Ideally you'd have a stack of images, like a base image that takes big context (with code/assets) + smaller images that build from that but have very small contexts. I wrote some ideas about that here if you have patience (it's a bit too long read).

Basically what I'm saying is that you got no choice but to mount stuff in a development scenario :-)

Regarding the buildout problem, I suspect a src-layout can solve the problem:
  • you only mount ./src inside container
  • you can happily run buildout inside the container (assuming it don't touch any of the code in src)

I suspect you don't need to run buildout for every code change so it's fine if you stick that into the image building.

-- Ionel
Cristian Mărieș, http://blog.ionelmc.ro