Allow use of alternate envvar(s) to $HOME for user modules

[ocaisa]

The use of $HOME for user modules is quite restrictive, it makes it very difficult to share user space installations. Even if we use a symlink to an accessible space it is still problematic as the root directory is still placed into the module (with $HOME expanded).

The nice thing about $HOME is that it is guaranteed to exist and right now that is required by module file that we create. Nevertheless, if a site is willing to take on using another (configurable) variable instead (with a sensible default value, such as $HOME), it would make user space installations with a module hierarchy a lot more flexible.

[ocaisa]

@boegel This is also interesting for EESSI since it would allow sites to easily configure a stack built on top of the EESSI baseline

[akesandgren]

Ha, nice. I have had vague thoughts in this direction a few weeks ago...

[boegel]

@ocaisa It would be nice to have a more complete test for this, where the generated module file actually gets loaded, and the effect on the changes in the environment are checked.

That may be a significant additional effort though...

[ocaisa]

@boegel Regarding having an end-to-end test for this, that is indeed additional effort and I don't really see the point. We currently check for the exact text we expect to find in the module file, the only additional thing that could be done is to make sure of the order.

[ocaisa]

@ocaisa It would be nice to have a more complete test for this, where the generated module file actually gets loaded, and the effect on the changes in the environment are checked.

That may be a significant additional effort though...

@boegel Ok, I found a relatively easy way to do this

[ocaisa]

@akesandgren Can you take a look at this to see if it makes sense for you too? We kind of need this so that we can create additional installations shared among a project as opposed to (or as well as) just for a single user.