We are currently using Conda for Python installation management on Windows, mainly so we can use the msys2 packages to pull in a gcc and make to build and run cocotb. We have had issues with Windows CI in the past (#1909) with sqlite.dll not being on the path, and again recently with cocotb not being importable.
Both have the same root cause: tox using virtualenvs is not compatible with the weirdness of conda installations on Windows. Compare a tox environment with a top-level miniconda environment and you'll see significant differences. All, the tests tend to pass when not using tox.
There are 2 alternatives here:
tox-conda and move conda requirements into tox.ini. I'm not sure how this will affect regressions in non-conda environments like Linux and MacOS.I'm in favor of 1.
I just had issues with tox-conda last week.
Essentially it doesn't add the default paths for each tox-created environment that would normally be added by conda activate.
So if you don't have the msys2 packages installed in the base environment but put them under conda_deps in tox.ini, it won't work.
I added this as a workaround:
[testenv]
# tox-conda doesn't add conda environment paths to PATH so here's a workaround
setenv =
PATH = {envdir}{:}{envdir}/Library/mingw-w64/bin{:}{envdir}/Library/usr/bin{:}{envdir}/Library/bin{:}{envdir}/Scripts{:}{envdir}/bin{:}{env:PATH}
tox-conda definitely has issues, and it looks to be abandoned. That's why I prefer 1. There is also the issue of specifying install_command for windows causing it to installing dependencies from source rather than wheels. I don't know if that might cause issues, but it's certainly slower.
If further isolation is required in 1 we can just make a new conda environment with conda create and put exactly what we want in it.
I will apply this change to my PR rather than pin virtualenv.
Would conda install --yes -c conda-forge tox help anything here?
I don't think so. The recipe doesn't seem to be introducing a patch set for the differences. Still might be worth testing.
Refs: tox-dev/tox#1648 msys2/MINGW-packages#7014
I don't know why I didn't realize this before, but it's a miracle this worked in the first place. We install packages into the global conda installation and then let tox create an isolated environment that is expected to use the globally installed msys packages? That's just totally wrong... tox-conda is actually the correct way (and only way?), but as we have seen, isn't a good solution. So I think not using tox on Windows is the best play.
Hopefully one day we can move away for needing msys2 to install and run cocotb on Windows.