I've seen the docs for using modules from upstream repositories here:
I was hoping that it meant that I could use Lmod modules and the
`module` command with a chained pair of spack installations. I
haven't been able to make that work.
I've found that I can use `spack load` to load packages from both
Spack installations, but this doesn't seem to use any modulefiles (if
I move the downstream `spack/share/lmod` dir somewhere else, `spack
load app` still works).
What's the take-home message of the
`using-modules-for-upstream-packages` page supposed to be?
Here's the upstreams.yaml file I'm working with:
```
upstreams:
spack-20200417:
install_tree: /local_scratch/george.hartzell/spack-20200417/opt/spack
modules:
lmod: /local_scratch/george.hartzell/spack-20200417/share/spack/lmod
```
I set up a shell to use an particular Spack tree by sourcing a shell
script like this one:
It:
- sources the `bash` script it finds in `$(.../bin/spack location -i
lmod)/lmod/lmod/init`,
- uses the `Core` dir that it finds beneath `share/spack/lmod`,
- loads the core compiler,
- then loads a set of modules.
In a downstream tree with nothing installed (and therefor no lmod
modules), this doesn't work.
If I install something, then Spack generates a lua modulefile for it,
but I can't use it because I can't load a modulefile for the Core
compiler (that modulefile lives upstream).
If I do a `module use <path/to/upstream/share/spack/lmod/.../Core`
then I can load the gcc module from upstream and that unlocks the
modulefiles for all of the upstream spack packages.
But, it doesn't make available the modulefile for the things in the
downstream tree.
On the other hand, if I don't use my initialization scheme but instead
source `.../share/spack/setup-env.sh` and use `spack load ...` then I
can see packages in both the upstream and downstream. But, this
prevents me (I think...) from using Lmod modulefiles to add non-spack
things to my users environments.