Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle mutliple backends for virtual environments #313

Closed
pytoxbot opened this issue Sep 17, 2016 · 7 comments
Closed

Handle mutliple backends for virtual environments #313

pytoxbot opened this issue Sep 17, 2016 · 7 comments

Comments

@pytoxbot
Copy link

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?

@pytoxbot
Copy link
Author

Original comment by @ssbarnea

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.

@pytoxbot
Copy link
Author

Original comment by @flub

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.

@pytoxbot
Copy link
Author

Original comment by @Steap

@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.

@pytoxbot
Copy link
Author

Original comment by @flub

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?

@pytoxbot
Copy link
Author

Original comment by @flub

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.

@pytoxbot
Copy link
Author

Original comment by @hpk42

there were some discussions on adding hooks to make isolation handling more generic through tox plugins. Mainly in the context of "conda" so far. I think @flub came up with it. If you or your companies would like to support this effort, we are doing a sprint in June 2016 and you have the possibility to influence the sprint focus, or prioritiers on issues, see here: https://www.indiegogo.com/projects/python-testing-sprint-mid-2016/x/4034848#/

@obestwalter
Copy link
Member

I will close this now in favour of #338 to focus the discussion.

@tox-dev tox-dev locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants