|
From: Xavier D. <xav...@gm...> - 2021-10-16 12:33:34
|
Hi Michael, I have just added an issue to update sh-to-mod sub-command and source-sh on version 5.1 and filter-out the environment variables sets by Modules which are intended for its own internal use. https://github.com/cea-hpc/modules/issues/427 Best regards, Xavier Le jeu. 14 oct. 2021 à 14:33, Sternberg, Michael G. <ste...@an...> a écrit : > > 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)' > |
