Fix conda current environment detection on github actions

[smarie]

On github actions the following command does not output the right environment's package list:

session.run(*["conda", "list"])

I am not sure if this is because the command is run from a specific shell (I use shell: bash -l {0} in the workflow definition file).

I am able to fix this by using explicit environment variables, this is equivalent to the "conda activate " command according to this source and also this one:

session.run(*["conda", "list"], env={"CONDA_PREFIX": session.bin, "CONDA_DEFAULT_ENV": session.get_session_id()})

The result of both commands (without the fix and with the fix) can be seen on the workflow here. You see that the first displays

nox > conda list
 # packages in environment at /usr/share/miniconda/envs/noxenv:
...

while the second displays:

nox > conda list
 # packages in environment at /home/runner/work/qdscreen/qdscreen/.nox/tests-2-7:
...

Note that for some reason on my local computer session.bin contains the conda env root folder, while on github actions runner this session.bin contains the <conda_env_root>/bin subfolder so I have to remove the "/bin" suffix... any reason why this is so ?

Anyway, this experiment makes me think that maybe it would be a good idea to always add those two environment variables to the env when the backend is conda, in order to mimic the behaviour of activate.

What do you think ?

[theacodes]

Note that for some reason on my local computer session.bin contains the conda env root folder, while on github actions runner this session.bin contains the <conda_env_root>/bin subfolder so I have to remove the "/bin" suffix... any reason why this is so ?

No idea. Someone with more conda experience would have to chime in.

Anyway, this experiment makes me think that maybe it would be a good idea to always add those two environment variables to the env when the backend is conda, in order to mimic the behaviour of activate.

Probably, but again, someone with more experience with Conda would have to make the call.

[henryiii]

I think this is correct - @chrisburr, would you know if env={"CONDA_PREFIX": session.bin, "CONDA_DEFAULT_ENV": session.get_session_id()} should be sufficient to use the correct environment (assuming session.<stuff> is correct)?

Also, the problem in GitHub Actions could be brought up to the setup-miniconda team, perhaps, if it's more general than this (though it generally has worked fine, so perhaps this is a setup issue?).

When adding tests for #448 this might show up.

[chrisburr]

I think I might be missing some context but I'll try to give some information and you can let me know if I've misunderstood. In particular I'm not sure what this session object is and session.bin looks like it would end in /bin and therefore never be a valid value for $CONDA_PREFIX.

It is impossible to correctly activate an arbitrary conda environment by setting environment variables[2] because there can be activation scripts[1] that must be ran for some packages to behave correctly. This is generally avoided but in some cases it's really necessary (e.g. the compiler packages).

[1] The documentation on this isn't very complete, e.g. fish/csh/xonsh/powershell scripts are also supported but not mentioned.
[2] I've used BASH_ENV to do some tricks here but that's more like running code than setting an environment variable

[smarie]

@chrisburr the issue is that when a nox script runs, it will spawn each command into an independent subprocess (using the usual python subprocessing module). With this mechanism it is relatively easy to pass environment variables along with the command, however I don't think that we can execute a pre-command (the activation command) prior to the actual desired command. Besides this is not even executed in a shell, so the activate command might as well fail.

Finally, from my experience, setting the environment variables works most of the time (I mean, I use conda in many different projects and have never seen a situation where this would not work - probably because I do not use exotic packages)

The current situation in nox is worse: we just add the <env> and <env>/Scripts folders (on windows) or the <env>/bin folder (other platforms) to the PATH and run the sub process. See CondaEnv