Force deactivation of existing conda environment in distribution scripts

[djhoese]

I had this issue and now a user has reported it too. If you have a conda environment active already and then run SIFT.sh from the distributed software bundle, when it goes to use conda-pack's activate script it just silently stops and exits. I think this is maybe a larger issue upstream in conda-pack, but could also be by design. A simple workaround would be to deactivate any conda environments before activating the conda-pack'd environment.

[djhoese]

As far as I can tell this chunk of code in the conda-pack activation is supposed to detect this:

https://github.com/conda/conda-pack/blob/08e83ca4cf3231a5efa5eab74051a284b75e0b09/conda_pack/scripts/posix/activate#L35-L47

It could be that this needs to be updated to use conda deactivate instead of deactivate.

Edit: No deactivate is actually a script and it just runs conda deactivate. So I'm back to not knowing what's going wrong here.

[djhoese]

https://github.com/conda/conda-pack/issues/270

This likely only happens when a mamba environment has been activated because the deactivate script does not exist. It is deprecated in conda environments, but hasn't been removed yet.

[ameraner]

I've been looking at this since we are seeing some issues with some (EUM) user setup, when multiple environments are activated sequentially on the user machine. Even if the . deactivate is reached inside the conda-pack, only one of the conda envs is deactivated, which causes issues when loading libraries...

I found that manually deactivating all envs in the SIFT.sh script fixes the issue:

if [[ -n $CONDA_SHLVL && $CONDA_SHLVL -ge 1 ]]; then
    echo "Deactivating conda env(s)"
    for i in $(seq ${CONDA_SHLVL}); do
        conda deactivate
    done
else
    echo "No activated conda env was found"
fi

or, I guess more ugly, manually unsetting the conda prefix also works

unset CONDA_PREFIX

---

On a side note, I also needed to

unset QT_PLUGIN_PATH

since this remains set after deactivating the envs, and it can cause library loading failure if it points to the external /path/to/conda/plugins (instead of the packaged SIFT_folder/plugins)

[djhoese]

Whoa I've never seen/used nested conda activate calls before. What is wrong with people :wink:

I definitely vote for the for loop version of deactivating. For the QT_PLUGIN_PATH issue, that should be considered a bug in the conda-forge package. I'm just not sure if/where to file it.

[djhoese]

Hm on my Ubuntu/PopOS system, an environment with Qt from conda-forge doesn't have that environment variable when activated.

[ameraner]

Yeah, I'm not sure either and I don't know how this conflicting conda env was built - I cannot reproduce on my own environments either.. I think we're hitting some strange corner cases with the setups here, but with the solution above we're on the safe side I believe.

[djhoese]

I would assume that the QT environment variable would be tied to the Qt package version. Like, some bug fix in Qt itself or in the conda package changed it being needed or set.