Why the shift from module load to conda?

I know the shift from module load root to conda activate /usr/nevis/conda/root can be annoying. These are the reasons why I'm taking the transition from CentOS 7 to AlmaLinux 9 as an opportunity to implement the environment-setup change.

• The reason why I strongly recommend moving to conda is that a conda environment is OS-independent (at least with respect to CentOS 7 and AlmaLinux 9), but an environment module is not.
• module load root, in and of itself, was always subject to my whim. Once or twice a year, I'd compile new versions of ROOT and Geant4 and announce something like "Use module load root for this new version; use module load root/6.10 to stick with the old version." So my proposed scheme is more-or-less what we're doing now, except that using conda will preserve execution environments across OS versions, and can free you from my impulse to keep using the latest-and-greatest.
• Users have a confused idea of what module load does. In one script I saw during the course of my work, a user had the statements:

  module load root/06.24.00
  
  # Initialize ROOT Environment Variables
  export ROOTSYS=/usr/nevis/el7/root-6.24.00
  export PATH=$PATH:$ROOTSYS/bin
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTSYS/bin
  export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$ROOTSYS/bin
  

  In other words, they invoked module load to make changes to their environment variables, and then added the exact same changes to the environment variables that module load root/06.24.00 did!

  It's my hope that switching to conda might bring some consistency and sanity to constructing environments, instead of treating my environments like a mysterious black box.

• The module load command isn't going away; it's just that it will stop working for the modules that I created under CentOS 7. If you have your own environment modules, they will still "work", in the sense that they'll modify $PATH and other shell variables; but their programs probably won't execute since they were compiled in an older OS.
• If you're using "module load" to handle your analysis tools, are any of those tools purely local (e.g., you developed a program called AnalysisFilter that's defined within an environment module) or are you using fairly standard analysis tools that you've installed within an environment?

  If it's the latter, I'd suggest looking whether those tools are available via conda; e.g.,

  conda create -n our_tools ctools=2.0 root jupyter python=3.7 compilers
  

• As for my standard environments: If you need a stable environment, my suggestion is to follow the recipe I give for cloning that environment that I give in the conda topic. to fix the versions. Then add your software tools to that; something like

  conda create -y --prefix /usr/nevis/conda/root --clone /nevis/olga/data/jsmith/envs/our_tools
  conda install -y --prefix /nevis/olga/data/jsmith/envs/our_tools ctools=2.0
  

  That will give your group complete control over the versions and software that you'd like to use.

• The chief disadvantage of using conda is that, unlike environment modules, they're not additive (and they also take up far more disk space). You couldn't do:

  conda activate /usr/nevis/conda/root
  conda activate /nevis/olga/data/jsmith/envs/our_tools
  

-- William Seligman - 2023-12-08