.condarc envs_dirs: breaks install_sct
#3982
Assignees
Labels
installation
category: install_sct or pip/setup.py
user requested
Raised by user on the SCT forum/email/GitHub. Be sure to notify them when fixed in a release.
Milestone
Comments
FixI think we should be able to paper over this by replacing Line 596 in a0aff11 with and Line 611 in a0aff11 with Actually it wasn't quite that, but close: p115628@joplin:~/spinalcordtoolbox$ git diff
diff --git a/install_sct b/install_sct
index e3ef9d80..0a0f7170 100755
--- a/install_sct
+++ b/install_sct
@@ -593,7 +593,7 @@ find "$SCT_DIR/$PYTHON_DIR" -type f -exec touch {} +
# create conda environment
print info "Creating conda environment..."
-python/bin/conda create -y -n venv_sct python=3.8
+python/bin/conda create -y -p "${SCT_DIR}/${PYTHON_DIR}"/envs/venv_sct python=3.8
# Reapply the touch fix to avoid `pip` connection issues on WSL
find "$SCT_DIR/$PYTHON_DIR" -type f -exec touch {} +
@@ -608,7 +608,7 @@ echo "include-system-site-packages = false" > "$SCT_DIR/$PYTHON_DIR/envs/venv_sc
# shellcheck disable=SC1091
source python/etc/profile.d/conda.sh
set +u #disable safeties, for conda is not written to their standard.
-conda activate venv_sct
+conda activate "${SCT_DIR}/${PYTHON_DIR}"/envs/venv_sct
set -u # reactivate safeties
# double-check conda activated (it can be glitchy): https://github.com/spinalcordtoolbox/spinalcordtoolbox/issues/3029The installer worked (modulo the current #3980 problem) But this fix feels like polishing a dusty stone. Can we do better? |
|
So, if I'm understanding correctly, the problem here is twofold:
The proposed fix addresses 2. by explicitly specifying a path via
Snce SCT's goal is to be a completely isolated environment, separate from any existing conda installations, then ideally SCT's installer would address 1., too, by ignoring any and all In that case, what if we were to specify our own (sensibly defaulted)
This would let us deal with the entirety of (Though, perhaps this has some unintended consequences? For example, if a user in a heavily-censored region has set |
|
Ah nice. I think setting those envs is a better solution than Since SCT's current design is container-ahoy, let's use |
Agreed! There are some dev instructions that involve
👍 |
|
Re: I was going through past (unresolved) forum posts and noticed: https://forum.spinalcordmri.org/t/failed-download-sct-5-7-linux/952/3?u=joshuacwnewton It turns out that this wasn't the first time we've run into |
joshuacwnewton
added
the
user requested
|
It turns out, for reproduction purposes, you don't even need to install Miniforge proper. All that's needed to break the installation is the presence of a # ~/.condarc
envs_dirs:
- ~/miniforge3/envs/joshua@tadpole:~/repos/spinalcordtoolbox$ python/bin/conda create -y -n venv_sct python=3.8
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/joshua/miniforge3/envs/venv_sct |
|
To try fixing this, I added a $SCT_DIR/.condarc# $SCT_DIR/.condarc
envs_dirs:
- ./python/envsjoshua@tadpole:~/repos/spinalcordtoolbox$ CONDARC=.condarc python/bin/conda create -y -n venv_sct python=3.8
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/joshua/repos/spinalcordtoolbox/python/envs/venv_sctThis works! However, there's a big caveat. Earlier, I said:
I had hoped that setting To test this, I tried:
And in all 4 cases, the conda environment continued to be created in Given that |
|
The more I read conda's documentation, the more I like @kousu's original proposal of using the
My stance here is informed by conda's Managing environments documentation; the use-case described for
Isolated environments? Perfect! By comparison, the (Besides, adding our own |
|
Sometimes what goes around comes around 🤗 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
If an env named
venv_sctpredates running./install_sct, the installation will fail.Steps to Reproduce
Install miniconda from https://github.com/conda-forge/miniforge
Set up this condarc
Download and run
install_sct.Expected behavior: SCT installs and works.
We're using
conda, in fact installing an entirely separate copy of conda regardless of whether the user has it on their system already, because we are very concerned about controlling exactly what is in the environment and where.Actual behavior:
Install fails at
Discussion
This was discovered by @dpapp86. He was trying to use https://github.com/shimming-toolbox/fsleyes-plugin-shimming-toolbox/ which copied the conda installing code from SCT, and additionally had a third install of conda just so he could install fsleyes 1.5.0 (shimming-toolbox currently pins 1.4.x). So, three condas at a minimum, plus several sub-environments.
I'm not sure which of them was responsible for creating
.condarc. Presumably at some point something ranconda config --append envs_dirs ....because at the time we found it he had:conda doesn't really live up to its promise as an isolation tool!
I recall (link somewhere?) that we discovered that creating or loading conda envs while already nested inside a conda env could be glitchy in incredibly difficult ways.
Here, I've discovered more ways this can fail: conda uses global ~/.condarc and ~/.conda/environments.txt, no matter which particular conda you're calling from.
But we are using it expecting that by installing to
~/spinalcordtoolbox/python/then everything will be contained in that one folder. I assume we got the idea from the full FSL package which also does this, and now shimming-toolbox has copied the habit, adding to the complication.The text was updated successfully, but these errors were encountered: