Cocotb: CI regressions on Windows

Created on 30 Sep 2020  路  8Comments  路  Source: cocotb/cocotb

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.

categoryWindows tests-ci bug

All 8 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

themperek picture themperek  路  3Comments

dukelec picture dukelec  路  6Comments

marlonjames picture marlonjames  路  8Comments

mkzo7 picture mkzo7  路  6Comments

jwprice100 picture jwprice100  路  9Comments