CI regressions on Windows

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:

1. Don’t use tox on Windows. This is fine, we are booting a new VM, installing miniconda afresh. Tox is actually not offering us much in terms of isolation this instance.
2. Use 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.

[ktbarrett]

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.

[eine]

Refs: tox-dev/tox#1648 msys2/MINGW-packages#7014