[TIP] [tox rfc] Adding a plugin model for tox environments and dependencies

holger krekel holger at merlinux.eu
Mon Apr 13 08:21:51 PDT 2015

Hi Chris,

On Mon, Apr 13, 2015 at 07:56 -0700, offline at offby1.net wrote:
> All (Holger, specifically);
> I’d like to propose (and implement) some changes to Tox to enable me to plug in (at a minimum) the following things:
> * dependency resolver
> * environment creation
> * process launcher
> The issue that’s driving this is that within my company we currently have a build system/packaging system for multiple versions of Python that is driven by a homegrown environment builder and setup launcher. Tox is ostentatiously better at those activities than the one we have, but because we use a dependency model that doesn’t map to the pip one — up to the point of even internalized names for some packages, and no concept of version ranges — and an environment build that is similar in character to a chroot, Tox as it currently exists is unsuitable for me.
> However, if I can add support at the tox.ini level for selecting a different tox environment builder, dependency resolver, and executable finder, then I can plug in my own implementation of these that would allow me to use the tox description of what to build — the commands, environments sections, python versions, et al — but integrate the way we define our dependencies and interpreters.
> I don’t want to go to the effort of doing this if the patch won’t land, though, and I’m not interested in forking tox at this time (although the existence of Spiny suggests an alternative path if needs be) so before I start down the path I’d like some hint of what would be the likelihood of landing this.

I've pondered a plugin system for tox and wanted to re-use pytest's plugin manager
for that as it's pretty mature.  My basic idea is to be able to have a
"tox-myplugin" release which pulls in tox as a dependency and would
implement extra functionality via hook functions.

Alternatively there could be options in tox.ini like the already "install_command"
which allow to outsource certain activities.  But i suspect it would be a bit
cumbersome and user-unfriendly (YMMV).

Another idea i didn't pursue yet was to think up a concept of "tox drivers", 
e.g. testing drivers like "pytest", "nose", "unittest" so that you wouldn't
need to specify all kinds of options and tox could offer "common options"
that can be used with all drivers.  Maybe something like this could work
for the other areas you touch.

In any case, i am open to help with reviewing, make something happen
that satisfies your use case, preferrably with some monetary funding
as i don't think it's just an hour or so that needs to go into it.


More information about the testing-in-python mailing list