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

[Jim Fulton]

On Wed, Jun 15, 2016 at 5:39 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> Op 15-06-16 om 13:53 schreef Jim Fulton:
>>
>>
>> 1. 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.

>
>> 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.
>
>
> 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.

Jim

-- 
Jim Fulton
http://jimfulton.info