Allow for the use of lmod modules
chrisjsewell opened this issue · 1 comments
Originally posted by @chrisjsewell in discussion with @albgar in marvel-nccr/ansible-role-siesta#12 (comment)
The libxc role does not currently install shared libraries. A client then needs to disable shared library support (e.g. in libgridxc) to use it. A role variable could be used to request shared libraries. However, this introduces more complications: what would happen if another role further down on the QM installation list actually installs a libxc-dev package, which has precedence in the shared libs search path?
Yes I must admit, I'm not an expert in the use of shared libraries.
I did have a brief look before, if there was anything similar to python/conda virtual environments in the "apt world", but I didn't see anything obvious (although now that you mention lmod I guess that is somewhat similar).
Any good reading/resources you could point me to would be welcome.
Regarding the installation path, I see it as a welcome development that you are using sub-directories in /usr/local. Could everybody else do so? It would be good to have things in /usr/local/siesta-x.y.z, for example, in case we want to install different versions. Actually, support for modules (of the lmod kind) might be good too.
Obviously the drawback is that the executables will not then be in the $PATH by default, and its just not something we have needed for now in Quantum Mobile, where we only have a single version of each code, and don't necessarily require the extra complication.
But yes I could see lmod as useful for the more general use of these roles.
Perhaps using something like https://github.com/idiv-biodiversity/ansible-role-lmod (this only supports redhat though)
Then each role could write a ModuleFile and also, in some way, contribute to a meta module that just loads the "default" versions of all codes (a bit like how we have the release_notes role for generating a single file of all code versions).
I'm not against adding support for a modules system in Quantum Mobile if it is a small dependency (which it probably is) and if it makes it easier for others like @albgar to install multiple versions of a code side-by-side.
The fact that it is so widely used on HPC centers certainly suggests that it works well for this use case (I'd like to understand though whether we should support lmod or the original modules ).
However, having multiple versions of codes is not the typical use case for Quantum Mobile - we typically want to offer one environment with one version of each code and make it as easy to use as possible.
I.e. it's fine to experiment with it for one code, but we should think hard before rolling it out more widely.