-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Force deactivation of existing conda environment in distribution scripts #370
Comments
As far as I can tell this chunk of code in the conda-pack activation is supposed to detect this: It could be that this needs to be updated to use Edit: No |
This likely only happens when a |
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 I found that manually deactivating all envs in the 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 |
Whoa I've never seen/used nested I definitely vote for the |
Hm on my Ubuntu/PopOS system, an environment with Qt from conda-forge doesn't have that environment variable when activated. |
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. |
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. |
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.The text was updated successfully, but these errors were encountered: