-
-
Notifications
You must be signed in to change notification settings - Fork 525
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
Comments
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. |
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. |
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. |
Original comment by @flub I notice in your blog post you experimented with a simple What do you think about these choices? Are there other options not yet considered? |
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. |
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#/ |
I will close this now in favour of #338 to focus the discussion. |
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?
The text was updated successfully, but these errors were encountered: