|
From: Sternberg, M. G. <ste...@an...> - 2021-10-14 12:33:31
|
Xavier, Indeed, thank you for integrating this! Now that "module sh-to-mod" is implemented internal to modulecmd.tcl, an interesting question and opportunity comes up: Would it be useful – or even necessary for consistency – to have sh-to-mod *filter out* (i.e., not issue) modifications of module-internal variables, like I did pragmatically with grep? Such internals would not be of interest for later deployment of the generated module, and make for an "Inception" challenge to modulecmd on eventual load. Having module invocations already occur in the input is certainly an edge case, but one that could well come up in porting situations. Michael Strelnikov: Could you illustrate the motivation of your question? With best regards, Michael > On Oct 13, 2021, at 23:50, Xavier Delaruelle <xav...@gm...> wrote: > […] Please note that the createmodule.py script has been replaced by the > "sh-to-mod" sub-command of module: > https://modules.readthedocs.io/en/latest/MIGRATING.html#sh-to-mod-sub-command > Regards, > Xavier > > Le jeu. 14 oct. 2021 à 02:10, Sternberg, Michael G. via > Modules-interest <mod...@li...> a écrit : >> >> […] you could let Modules itself do the work of gathering and interpreting the accumulated changes of environment vars: >> echo module load foo > /tmp/foo.sh >> createmodule.py /tmp/foo.sh \ >> | grep -Ev '(_modshare|MODULES_LM|_LMFILES_|LOADEDMODULES)' |
