Miniconda provides conda envs to create isolated Python environments similar to
virtualenv. Its main advantage is that conda environments also isolate the binary shared library dependencies from the rest of your machine. Unfortunately, conda does not support virtualenvs because of the difference in how they manage shared libraries.
Since Miniconda isolates its shared library dependencies from the rest of your machine, virtualenvs which are created by a Miniconda-based environment fail during creation time. The virtualenvs will attempt to use shared libraries in the system-level location, but not the Miniconda location.
NOTE: If you try to create virtualenvs using Miniconda in an environment which already has the correct shared libraries in the system-level location, then your virtualenv will seem to succeed. However, any shared libraries which were only installed using conda will fail at runtime. Because of this, testing this feature should be done in an isolated environment.
I believe that the first implementation of this feature has these requirements:
- Create conda environments instead of virtualenvs based on a single miniconda Python version
- Install pip using conda by default
- Add dependencies using pip (like virtualenvs)
Further features which are necessary for complete conda env supports are:
- Create conda environments for multiple miniconda Python versions
- Allow the installation of conda packages along with pip packages
There is a similar project called ctox (https://github.com/hayd/ctox) which tries to implement this. However, it doesn't have any guarantees on reliability. This project was actually started around the time there were comments on this ticket (https://bitbucket.org/hpk42/tox/issues/167/add-an-option-to-run-commands-after) about conda.
I would like to work with the tox team on specifying any additions necessary for conda support in Tox.