[PATCH v3 4/5] tox: Integrate tox-docker

[Stephen Finucane]

On Thu, 2019-08-22 at 23:52 +1000, Daniel Axtens wrote:
> > >  .. code-block:: shell
> > >  
> > > -   $ tox -e py27-django18
> > > +   $ tox -e py36-django21-mysql
> > 
> > So I'm trying this out (finally!) and it seems to want to install all
> > the dependencies locally before starting a container. I don't have the
> > mysql bits installed, so it fails looking for `mysql_config`. Is this
> > supposed to happen or am I Doing It Wrong?
> > 
> 
> Ok, so on further analysis it looks like this is the designed behaviour:
> that when running tox, all the python versions and local dependencies
> would live on my laptop directly rather than in a docker container.

Correct.

> If so, I'm not a fan. I am not primarily a web, python, or database
> developer and I like having all of that stuff live in an isolated docker
> container. I especially like that it's also consistent for everyone who
> wants to hack on patchwork - that they can run the full suite of tests
> across all the supported versions with nothing more than docker and
> docker-compose. tox-docker provides, afaict, no way to do this. (Also,
> less universally, I run Ubuntu, not Fedora and getting multiple python
> versions is a pain, as you can see from the dockerfiles.)
>
> What's the main problem that you're trying to solve here? Is it that you
> have to type 'docker-compose run web --tox -e py36-django21' rather than
> just 'tox -e py36-django21'?

Personally, I'm finding I'm having to jump through a lot of hoops to
get docker working as I expect, including things like needing to create
the '.env' file so it uses the right UID, and it also takes _forever_
to rebuild (which I need to do rather frequently as I tinker with
dependencies). Finally, it doesn't work like I'd expect a Python thing
to usually work, meaning whenever I go to tinker with Patchwork after a
break, I need to re-learn how to test things. Given that I have an
environment that already has most of the dependencies needed to run
this, I'm not really getting any of the benefits docker provides but am
seeing most of the costs.

How about we don't strip the 'web' Dockerfile to the bones and instead
add this as an alternate approach to running tests? I get faster tests
and you still get full isolation. Alternatively, we can switch to pure
Python DB drivers (removing the need for non-Python dependencies) in
our development requirements.txt and use pyenv to provide multiple
Python versions? That avoids having two ways to do the same thing but
does still mean you need a little work on your end, which might not be
desirable.

Stephen

> Regards,
> Daniel