Make use of tox-conda optional

[saimn]

Currently if tox-conda is installed and conda-deps is defined, this raises an error.
To make it easier to share a tox config for conda and non-conda envs, it would be useful to either continue with the default tox process, or maybe better to have a setting to activate tox-conda on a per env basis ?

[drdavella]

@saimn this is a good idea. Can you share an example of the error that occurs?

Do you think it would make sense to have another config option like use_conda that defaults to True but can be set to False for specific environments in a project's tox.ini file? In this case, tox-conda would simply pass through to regular tox for this environment, which would create a virtualenv and just use deps.

[drdavella]

We could also imagine providing a command-line option to enable/disable conda use on-the-fly, but this could be problematic. If I define conda_deps but then use this option to turn conda off for this environment, what will happen? Naively we could just append conda_deps to deps and let pip figure it out, but this probably won't work for all cases.

[saimn]

The error is if I install tox-conda on a non-conda env (I forgot to mention this above, sorry):

❯ tox -e py37
py37 create: /home/simon/dev/astropy/.tox/py37
ERROR: Error creating virtualenv. Note that spaces in paths are not supported by virtualenv. Error details: FileNotFoundError(2, "No such file or directory: 'conda'")

It's not all clear for me how to best manage this, and having a tox conf working on multiple environments.
A use_conda setting would be useful but requires to duplicate tox env for conda and non-conda and make use of tox factors. So the command-line option seems even better.
For dependencies, I think we can simply ignore conda_deps when conda is switched off. The packages can be duplicated in the pip deps, as pip will not reinstall them when using conda (I think).

[drdavella]

Ah, okay. That's a case I hadn't considered. So you'd like it to automatically determine if conda is not available and use a virtualenv instead? This will be tricky.

For dependencies, I think we can simply ignore conda_deps when conda is switched off. The packages can be duplicated in the pip deps, as pip will not reinstall them when using conda (I think).

This should be true. tox-conda actually already does this automatically in order to enable tox to recognize when an environment needs to be updated:

tox-conda/tox_conda/plugin.py

Lines 60 to 65 in 8cb9d2f

	# This is a pretty cheesy workaround. It allows tox to consider changes to
	# the conda dependencies when it decides whether an existing environment
	# needs to be updated before being used
	for _, envconfig in config.envconfigs.items():
	conda_deps = [DepConfig(str(name)) for name in envconfig.conda_deps]
	envconfig.deps.extend(conda_deps)

We could allow it to do this automatically when using a virtualenv also, so that dependencies don't need to be manually duplicated in the config. However, I'm not sure this is safe in all cases since a conda package name is not guaranteed to be the same as one on pypi, and there may not be an overlap in all cases.

[saimn]

About the first issue, when using tox-conda in a non-conda setup, I'm not sure what is the best. Thinking more about, just raising an error saying that conda is not found is probably the best solution, so what is done now.
About conda_deps, it can indeed packages that are not available with pip. So when not using conda I think it is safer to just ignore conda_deps.