Handle mutliple backends for virtual environments

Issue #313 on hold
Cyril ROELANDT created an issue

Currently, tox only handles "virtualenv" as a backend. There are other ways of creating isolated environments in which packages can be installed and tests can be run: one may want to use Nix (https://nixos.org/nix/) or Guix (http://www.gnu.org/software/guix/), two very nice functional package managers that can replace virtualenv+pip.

These package managers fix some issues witnessed when using virtualenv (the environment variables leak into the "isolated" environment, external commands can be used, etc.); they also have drawbacks: some packages available on PyPI may not be available in Nix/Guix, some features may not be supported...

I wrote a blog article explaining why one might want to move away from virtualenv (http://perso.aquilenet.fr/~steap//blog/2015/10/14/guix-tox/) as well as a proof of concept that allows users to use Guix as a replacement for virtualenv/pip (see the latests commits at https://git.framasoft.org/Steap/guix-tox/commits/guix-tox). Would you be interested in making tox a more generic piece of software, able to handle multiple package management backends?

Comments (8)

  1. Floris Bruynooghe

    Yes, I am interested in this for conda, but thanks for suggesting nix and guix, it shows the approach to enable environment creation from a plugin is the right one to take I guess. Unfortunately that's not something I'm currently actively working on, but it could be a good sprint topic I guess.

  2. Floris Bruynooghe

    I notice in your blog post you experimented with a simple --env option which completely switches the env creation to use guix rather then virtualenv. When I was playing before I was trying to aim for a configuration option, e.g. envtype = pyvenv|conda|guix to have in a env config section so that tox could create different kind of environments in one run. It also means that the env type is set in the file which is checked in, so that someone else will not accidentally forget to run it with the right env, as I don't expect envs to be compatible (different package names etc).

    What do you think about these choices? Are there other options not yet considered?

  3. Cyril ROELANDT reporter

    @Floris: thanks for your comments. Why would I want tox to create multiple kinds of environment in one run? What's the use case here? I do not think there should be a "right" env, everyone should be able to use whatever they want, which is why I thought an command line option was the best thing to do.

  4. Floris Bruynooghe

    A maintainer might want to support normal python 3.2-3.5 + anaconda/miniconda 3. But the more important part is that the type of environment should come from tox.ini as the package names will differ between different environments, and accidentally running a configuration with the wrong environment is going to lead to some confusion.

  5. Sorin Ionuț Sbârnea

    As conda is getting more and more supporters, as being the only fully working way to distribute binary packages across almost any platform, I would like to be able to test the packages that I am maintaining using various versions of python, including the conda ones.

    I would be more than happy to help on adding support for this to tox as I do see tox as the best way to perform matrix testing across different versions of python.

  6. Log in to comment