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

[Daniel Axtens]

Stephen Finucane <stephen at that.guru> writes:

> On Mon, 2019-08-26 at 14:25 +1000, Daniel Axtens wrote:
>> Stephen Finucane <stephen at that.guru> writes:
>> 
>> > 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.
>> 
>> Fair enough. How does this sound:
>> 
>> We copy the original tox.ini into tools/docker/
>> 
>> We make the main tox file the tox file you suggested, so that on your
>> laptop you can run `tox -e whatever` and things will go well.
>> 
>> In entry-point.sh, we intercept `--tox` and use the saved tox.ini file
>> for inside docker (tox -C tools/docker/tox.ini $@)
>> 
>> We have to keep the two files in sync, but then we have both systems
>> working as expected, and we can clarify in documentation when to use
>> each of them.
>
> I don't think any of that is necessary. As things stand, running e.g.
> 'tox -e py27-django111' will continue to have the same behavior as
> previously. The only change will happen if you introduce an additional
> factor and call something like 'tox -e py27-django111-mysql'. That's
> not included in any of the default environmnents by default so I don't
> think it's an issue.

I thought you were changing the default environment list - there's
a change to envlist in tox.ini:

> [tox]
> minversion = 2.0
>-envlist = pep8,docs,py{27,34}-django111,py{35,36}-django{111,20,21,22}
>+envlist = pep8,docs,py{27,34}-django111-{mysql,postgres},py{35,36}-django{111,20,21,22}-{mysql,postgres}
>+skip_missing_interpreters = True
> skipsdist = True

I'd really like to keep `docker-compose run web --tox` working, but
otherwise I'm happy to make whatever changes make things easy for
you. Perhaps we could specify default envlist using the TOXENV
environment variable in entrypoint.sh? Then you could change the default
tox.ini environments with no issues...

Regards,
Daniel

>
> Stephen
>
>> If you don't like that I'm happy to explore the pure python driver plus
>> pyenv approach.
>> 
>> Regards,
>> Daniel
>> 
>> > 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