On Wed, Jun 15, 2016 at 5:39 PM, Reinout van Rees email@example.com wrote:
Op 15-06-16 om 13:53 schreef Jim Fulton:
- Creating production docker images works best when all you're doing
is installing a bunch of binary artifacts (e.g. .debs, eggs, wheels).
That's where pip and its "everything is in requirements.txt anyway" has an advantage. The buildouts I use always have most/all dependencies mentioned in the setup.py with version pins in the buildout config. So I need the setup.py and so I need my full source code as the setup.py won't work otherwise.
No. If you had a built version of your project, the requirement information in the setup.py would still be available and used by buildout.
How you specify requirements is beside the point. Whether you use buildout or pip, you need built versions of your non-pure-oython dependencies available and used.
I *do* like to specify all "install_requires" items in my setup.py, so this is something I need to think about.
I don't see how this is a problem. If your project is pure python, you don't need build tools to build it, so building it as part of building a docker image isn't a problem. If it isn't pure Python, then you'll need to have a built version available, and the meta-data in that built version will provide the necessary requirements information.
I'm not trying here to plug buildout vs pip. I'm just saying that the pip vs builtout (or both) decision is irrelevant to building a docker image or docker workflow.
- 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.
docker-compose helps a little bit here in that you can "compose" your docker into several scenarios. It *does* mean you have to watch carefully what you're doing, as one of the goals of docker, as far as I see it, is to have a large measure of "production/development parity" as per the "12 factor app" manifesto (http://12factor.net/)
I think this only helps to the extent that it encourages you to decompose applications into lots of separately deployed bits.
I'm a fan of docker, but it seems to me that build workflow is a an unsolved problem if you need build tools that you don't want be included at run time.