On Wed, Jun 15, 2016 at 12:07 PM, Reinout van Rees <[email protected]> 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 <https://blog.ionelmc.ro/2016/05/07/dealing-with-docker/#optimizing-the-build-process> 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. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
