3

Here is my logic:

when you conda activate --stack ..., the only thing that is left over from the stacked-upon environment is its entry in PATH.

Therefore, if a conda environment can function normally with only it's entry in PATH, then it doesn't necessarily need to be activate'd, I can just add it to PATH myself:

export PATH=<conda-env-location>:$PATH

Is this true?

The question then is how do I determine which conda environments need to be activated and which can just be added to path?

My theory is that if the binaries in a given environment depend on python, then they shouldn't be stacked upon. CONDA_PYTHON_EXE changes, which python changes, import's from the stacked upon environment wouldn't work. Anything else is fair game.

Is this true?

Timur Shtatland
  • 12,024
  • 2
  • 30
  • 47
Simon
  • 51
  • 5
  • Retracting my previous comment: stacking does appear to run all package-specific deactivate scripts. This also has the implication that binaries in packages with activation scripts like `compilers` (e.g., `gcc`, `clang`) won't have the intended environment variables set when stacking, despite the binaries still being on PATH. So, you can add that to the list of things that probably aren't functional to stack. Generally, I don't think one can give a simple rule for what won't work with stacking, but instead need to be tested. Personally, I think stacking is not the panacea people wish it was. – merv Jan 23 '23 at 04:38
  • I routinely use just the path to `samtools` (a very common tool in bioinformatics), without activating the conda environment. It was installed with `conda`. This works for me on the Mac and on Linux. – Timur Shtatland Apr 25 '23 at 15:40

0 Answers0