mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armand Grillet <>
Subject Re: Replacing ad hoc virtualenvs for testing and linting with tox
Date Tue, 09 Jan 2018 14:29:30 GMT
Having distributed tox.ini files and being able to run tests for multiple
environments will be helpful to develop the new Mesos CLI thus I support
this change.

Requiring developers to install tox is indeed the biggest concern with this
change; however, this process should be straightforward as it uses pip.

2018-01-09 10:03 GMT+01:00 Kevin Klues <>:

> I'm the one who asked Eric to send this email. I've been meaning to
> comment on it and haven't gotten around to it. I support it. We just need
> to make sure and update our CI appropriately for the new dependency (and
> make devs aware of it).
> On Tue, Jan 9, 2018 at 4:03 AM Benjamin Mahler <> wrote:
>> +armand, benno, kevin
>> On Fri, Jan 5, 2018 at 12:04 PM, Eric Chung <> wrote:
>>> Hello mesos devs,
>>> I'd like to propose that we replace some of our bash scripts for building
>>> ad hoc virtualenvs with tox <>, a
>>> tool
>>> for automating lifecycle management of virtualenvs using declarative
>>> configuration files.
>>> Specifically, virtualenvs created for the purpose of linting
>>> (support/.virtaulenv) and unit testing (in src/python) can be managed by
>>> tox, which provide the following benefits:
>>> 1. Eliminate the need for maintaining shell scripts for managing
>>> virtualenvs
>>> 2. We will no longer need to install *ALL* dependencies into the same
>>> virtualenv for the purpose of linting -- we can have distributed tox.ini
>>> files in wherever python linting is required, and just run tox there.
>>> 3. Easily run tests for multiple environments, e.g. python3 vs python2.
>>> This will make migration to python3 much easier, which we are facing
>>> increasing pressure to address.
>>> The biggest concern here would probably the change in dependencies, since
>>> it may seem like we're adding an additional dependency to mesos. However
>>> since virtualenv is a dependency of tox, we will not break any existing
>>> dependencies, as requiring tox will automatically require virtualenv.
>>> Otherwise I don't really see any downside in making the switch.
>>> Please let me know what you think!
>>> Eric

Armand Grillet
Software Engineer, Mesosphere

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message