Problems when trying to use EB as a normal user with HMNS

[akesandgren]

We're trying to make it possible for normal users to use EB for installing some software that we can't, or aren't allowed to, install globally.

We want them to be able to do this while still utilizing our site setup with all the existing toolchains etc.
We are using HMNS, minimal-toolchains, and recursive-module-unload.

When trying as a normal user and just setting installpath EB doesn't find the already installed modules, except for the ones directly available in Core.

Is there anything we're missing or should be doing differently?

@geimer any thoughts on this?

[ocaisa]

In case you haven't seen it... #1472

[akesandgren]

I have, but I seem to have failed in reading all of it previously.

It actually talks about being able to do what we want, but there is no solution yet.
The comment from @geimer on Jan 20 2016, "And now the potential use case:" is precisely what we want to do.

What we have problems with is building software in the first place. I.e., EB not finding the already site installed modules that aren't in Core.

[geimer]

Unfortunately, #1472 isn't enough. EasyBuild searches for/loads modules with their full name, e.g., Core/GCC/6.3.0-2.27 or Compiler/GCC-6.3.0-2.27/OpenMPI/2.0.2. Thus it isn't enough to have the Core path in $MODULEPATH, but also it's parent directory.

Example: Suppose your system-wide EasyBuild prefix is /opt/eb, then modules end up in /opt/eb/modules/Core, /opt/eb/modules/Compiler and /opt/eb/modules/MPI. Presumably, you have /opt/eb/modules/Core in $MODULEPATH. But for user-local installs to work, you also need to set/add /opt/eb/modules to it. I currently do this by providing a module that adds the following wrapper script to $PATH:

#!/bin/sh
export MODULEPATH=/opt/eb/modules:${MODULEPATH}
${EBROOTEASYBUILD}/bin/eb "$@"

[geimer]

To be more precise: I have a module SoftInst which sets the desired EasyBuild configuration in the environment and loads the (hidden) EasyBuild module. If loaded as a "normal" user, it also modifies some settings (in particular EASYBUILD_PREFIX) and loads the (again hidden) eb_user module which extends $PATH to the location of the above script.

[akesandgren]

Ah, now stuff is starting to make sense :-)

Could you give me your SoftInst etc modules so i can take a look and see what we need to do.

And following that hint, --dry-run also works.

Nice.

[geimer]

@akesandgren Sent by PM.

I briefly discussed this with @boegel some time ago and we thought about adding an alt-prefix or alt-module-path (or similar) configuration option to let EasyBuild do the $MODULEPATH extension. But as usual, it ended up on the imaginary wish list and didn't materialize yet...

[akesandgren]

Regarding your SoftInst module, shouldn't EASYBUILD_REPOSITORYPATH really point to the users .local/ebfiles_repo or so? They shouldn't be allowed to write into the global repopath.

Never mind.... must read to the end...

[geimer]

That's what is happening. EASYBUILD_REPOSITORYPATH is unset for "normal" users, i.e., it uses the default $EASYBUILD_PREFIX/ebfiles_repo.

[akesandgren]

Regarding EASYBUILD_SUBDIR_USER_MODULES...
I'd like to have it set in the global easyconfig.cfg, would setting it to "" in SoftInst work just as well?

[geimer]

I believe empty strings are considered "unset" in Python, so probably yes. But I'm not sure.

[akesandgren]

We'll find out probably tomorrow. Just need to rebuild a couple of modules so the user-hmns part gets included.

[akesandgren]

WIth the SoftInst module from @geimer I now have this working to some extent.
Ran into some new bugs with module creation though.

[boegel]

see #2162 w.r.t. problems that @akesandgren referred to in previous comment

@geimer: W.r.t. the required $MODULEPATH extension, can't we derive that from the current $MODULEPATH and the subdirectory that points to the top of the module tree, which is specified in the module naming scheme?

[geimer]

@boegel Probably yes. So the idea would be to iterate over the paths in $MODULEPATH and try to strip off any path returned by mns.det_init_modulepaths()?

[boegel]

@geimer Basically, yes, that makes sense to me...