Right now auto_module_something is a “select” widget. That is, you’d have to pick a version for a given module name, exclusively.
I wonder if it would be possible to implement an “additive select” widget similar to what RIKEN OpenComposer has for jobs, to be able to add multiple modules by doing “select + add” multiple times?
If you have auto_module_something why would you want different versions of something available? Wouldn’t you actually want auto_module_otherthing in addition to something?
Yes! For several different modules, not for many versions of a single package. I suppose it is now possible to do it manually by creating a battery of “select” widgets for each auto_module_thing1,2,3,… However, there may be cases when I do not know which modules are of interest, or they are all optional.
An example is R. Users can use R with preinstalled packages or with pure R packages. Then auto_module_r covers it all, and an RStudio app works out of the box.
But if a user wants R to use with an R wrapper for JAGS, or if a user wants to use an R wrapper for GDAL, I would like them to be able to load an R module, and then add either the JAGS module or GDAL, because we have them on our central HPC stack. Either or both of these would be loaded in addition to the R module. Depending on how dependencies are handled on a particular HPC site, GDAL would also need HDF5, etc.
(There can also be a third package with a module on our HPC stack with a useful R wrapper, and I have no a priori idea of its existence. Such a module can be auto-gathered from the LMod list, if it is searchable. But I’d need to know of it now, and to update the form by hand to add the auto_module_thirdpackage. I guess this case would ask for some “search” capacity in addition to being additive. )