Fix deployment with latest conda (23.1.0)

[xylar]

It turns out that the boa package isn't compatible with the latest mamba, but the latest mamba is needed in order to use the latest conda. So when compass tries to update everything, things end in a bad state. (An error message relate to a missing no_user attribute occurs when running mamba.)

The solution seems to be not to include boa in the base environment for now. This won't affect compass, since boa is used to build conda packages and was just there for convenience (I sometimes need to build conda packages for compass maintenance).

Checklist

• Document (in a comment titled Testing in this PR) any testing that was used to verify the changes

closes #544

[xylar]

Testing

I installed a new Mambaforge with this code. I also used it on my existing Mambaforge installation. Both worked.

[xylar]

@trhille and @mark-petersen, you both ran into this. Can you see if you are able to run ./conda/configure_compass_env.py and if it fixes the problem for you? (Assuming you have an installation somewhere that isn't already manually fixed.)

@matthewhoffman, I don't know if you've run into this already but you likely will.

[mark-petersen]

Yes, this works without any trouble, thanks! I tested on chicoma, chrysalis, and cori with

./conda/configure_compass_env.py --conda ~/miconda3 --compiler intel

or similar, and it created the load_dev_compass_1.2.0-alpha.4_chrysalis_intel_openmpi.sh correctly.

[trhille]

I tested this on Perlmutter with the --with_albany flag, using my existing miniconda3 and mambaforge installs, and both successfully created load_dev_compass_1.2.0-alpha.4_pm-cpu_gnu_mpich_albany.sh.
One note is that when I used the mambaforge install, I got the following message upon sourcing the env load script, which I didn't get when using the miniconda3 install:

Loading Spack environment...

Inactive Modules:
  1) cray-netcdf-hdf5parallel/4.9.0.1

[xylar]

Not sure what to make of the spack and cray-netcdf-hdf5parallel thing but that seems a coincidence.

[matthewhoffman]

I merged this into another branch I'm working on for testing on perlmutter. Creating the new compass env worked successfully:

$ ./conda/configure_compass_env.py --conda ~/miniconda3 -c gnu --mpi mpich -m pm-cpu --with_albany --recreate
Logging to: conda/logs/prebootstrap.log

Doing initial setup

Setting up a conda environment for installing compass

Creating the compass conda environment


 Running:
   source /global/homes/h/hoffman2/miniconda3/etc/profile.d/conda.sh
   source /global/homes/h/hoffman2/miniconda3/etc/profile.d/mamba.sh
   mamba activate compass_bootstrap
   /global/cfs/cdirs/fanssie/users/hoffman2/compass/thwaites-uq-ensemble-deltaTsampling/conda/bootstrap.py --conda /global/homes/h/hoffman2/miniconda3 -c gnu --mpi mpich -m pm-cpu --with_albany --recreate

Logging to: conda/logs/bootstrap.log

Configuring environment(s) for the following compilers and MPI libraries:
  gnu, mpich

creating dev_compass_1.2.0-alpha.4

Installing pre-commit

Writing:
   /global/cfs/cdirs/fanssie/users/hoffman2/compass/thwaites-uq-ensemble-deltaTsampling/load_dev_compass_1.2.0-alpha.4_pm-cpu_gnu_mpich_albany.sh

However, when I went to load the new env, I got a strange spack error:

$ source load_dev_compass_1.2.0-alpha.4_pm-cpu_gnu_mpich_albany.sh
Loading conda environment
Done.

Reinstalling compass package in edit mode...
Done.

Loading Spack environment...
==> Error: No such environment: 'dev_compass_1_2_0-alpha_4_gnu_mpich_albany'
Done.

Trying again with a clean environment (fresh login), loading the env works correctly, so the previous error must have been a spack environment collision and can be ignored.

$ source load_dev_compass_1.2.0-alpha.4_pm-cpu_gnu_mpich_albany.sh
Loading conda environment
Done.

Reinstalling compass package in edit mode...
Done.

Loading Spack environment...
Done.

[matthewhoffman]

Approved based on testing and casual inspection.

[xylar]

@matthewhoffman, yes, I suspect that It's looking for the environment in an incorrect location, perhaps because you previously loaded a different spack (corresponding to a different version of mache) in a different branch. It seems you can't simply switch spack environments by sourcing new load scripts. I don't think there's anything I can do about that. You need a fresh terminal for each branch or worktree you're using if they happen to use different spack locations.

[xylar]

@mark-petersen, @trhille and @matthewhoffman, thank you for reviewing!