Messed up conda envs in build on Windows

[chrisjbillington]

The windows build fails with:

Traceback (most recent call last):
  File "make_packages.py", line 3, in <module>
    import toml
ModuleNotFoundError: No module named 'toml'

Despite that the workflow has:

conda install -c labscript-suite setuptools-conda && ^
python make_packages.py ${{ runner.temp }}

where setuptools-conda depends on toml.

The log output shows conda installing toml, however the job I'm looking at is supposed to be for Python 3.6, whereas some of the packages being installed are clearly 3.9 builds. So something is wrong about the conda environment setup. Like, the conda command is installing packages to one environment, but then the python command is a different environment (or different Python interpreter altogether).

Grumble grumble

[philipstarkey]

I wonder if a activate base command preceding the conda/python calls might sort it out?

Maybe the base windows image has Python installed now.

[chrisjbillington]

setup-miniconda is supposed to install and activate an environment called "test", in this case for Python 3.6, so if that would help it would presumably be "activate test".

So we have a conda command acting on a base environment (which is wrong, it should be "test"), and a python command apparently not from that base environment. Could be from the "test" environment, or a separate Python as you suggested. In either case it represents a broken environment activation, not merely the lack of activation (I think). This stuff is fragile enough that I'd like to find the root cause before deciding to apply a workaround in the form of more activate commands, even if that works!

It does seem like it must be either a conda change or a github windows image change (as you suggested). We're hard-coding which version of the setup-miniconda action to use, so it can't be that.

I'll test in workflow-sandbox and add some printlines to identify the Python interpreter, and keep an eye on the setup-miniconda bugtracker (nothing there yet) since I would have thought the issue would affect others. Might try out a newer commit of setup-miniconda - we're stuck on an old version because of a bug, but the fix has been merged (not in a release, but can point the workflow to a specific commit). If nobody else is experiencing the issue it might be because we're on an old version of the action.

Actually I'll do nothing for a little bit, since others might encounter the problem and put in the work so we don't have to. If not then I'll investigate as above.

[chrisjbillington]

Fix is to use a newer setup-miniconda. Don't know why the old one doesn't work, but it was failing to activate environments properly. Latest has no issues.

We were pinned to an old version of setup-miniconda because of a regression, now we need to use a commit newer than the latest release to include the fix for the regression.

Fix in workflow-sandbox: rpanderson/workflow-sandbox@8525772

Need to deploy this to every repo...