|
From: Roberto B. <Rob...@pi...> - 2022-06-03 07:54:35
|
Are there any examples of using module collections? Sometimes there are some potentially interesting features that would really need a set of examples to explain the main thinking and usage behind them. Before investing time in reorganizing modules to use a new feature one would like to fully understand advantages and limitations of a new feature. I perfectly understand that setting up a not too simple example of a certain feature might be tedious and time consuming, but I really think it would make new features more likely to be used. Roberto On Thu, Jun 2, 2022 at 8:43 PM Xavier Delaruelle < xav...@gm...> wrote: > Hi All, > > For the environment initialization, I would like to also suggest to look > at module collections [1] as an alternative to the init* commands. > > New version of the default initrc configuration file highlights a way to > restore default collection of user when their session initializes [2]. > > Combined with the collection_target [3] configuration option, it is > possible to have different set of collections for each defined target. And > it is up to you to define this target, based on how the environment you > provide has to be split (by os id name and version, by dns domain, etc). > > Regards, > Xavier > > [1] https://modules.readthedocs.io/en/latest/module.html#collections-1 > [2] https://modules.readthedocs.io/en/latest/INSTALL.html#configuration > [3] > https://modules.readthedocs.io/en/latest/module.html#mconfig-collection_target > > > Le jeu. 2 juin 2022 à 19:52, Jason Edgecombe <jwe...@un...> a écrit : > >> Hi Erik, >> >> Thanks to everyone for the excellent suggestions! I'm going to look at >> using your and Pierre's suggestion of handling the $DISTRO in the module >> files. I plan to keep the modules as close as possible between each distro. >> >> Thanks, >> Jason >> >> --------------------------------------------------------------------------- >> Jason Edgecombe | Linux Administrator >> UNC Charlotte | Office of OneIT >> 9201 University City Blvd. | Charlotte, NC 28223-0001 >> Phone: 704-687-1943 >> jwe...@un... | oneit.charlotte.edu >> >> --------------------------------------------------------------------------- >> If you are not the intended recipient of this transmission or a person >> responsible for delivering it to the intended recipient, any disclosure, >> copying, distribution, or other use of any of the information in this >> transmission is strictly prohibited. If you have received this transmission >> in error, please notify me immediately by reply e-mail or by telephone at >> 704-687-1943. Thank you. >> >> >> On Thu, Jun 2, 2022 at 1:36 PM Erik Parawell <eri...@si...> >> wrote: >> >>> Hi, >>> >>> I had the same issue. This is how we resolved it: >>> We have a file called os_detect.tcl in the root of our modules folder. >>> >>> https://gist.github.com/ErikParawell-SiFive/fac611a6fa8acb4868f9da420c3c43a5 >>> And this is what our module file looks like: >>> >>> https://gist.github.com/ErikParawell-SiFive/020b0d8774d49b5d2164ec141234bbe5 >>> >>> >>> >>> >>> On Jun 2, 2022, at 11:47 AM, Paul Markfort <pau...@gm...> wrote: >>> >>> Note. >>> >>> The module initadd script modifies the module load command in the user's >>> shell initialization scripts. >>> So, different locations for those files is what you need (hence the >>> suggestion of different home directories). >>> >>> Alternatively, users can learn to modify their own init scripts >>> (including adding in code to make decisions based on OS). >>> >>> From the man module page: >>> >>> initadd modulefile... >>> Add modulefile to the shell's initialization file in the >>> user's >>> home directory. The startup files checked (in order) are: >>> >>> C Shell >>> .modules, .cshrc, .csh_variables and .login >>> >>> TENEX C Shell >>> .modules, .tcshrc, .cshrc, .csh_variables and .login >>> >>> Bourne and Korn Shells >>> .modules, .profile >>> >>> GNU Bourne Again Shell >>> .modules, .bash_profile, .bash_login, .profile and >>> .bashrc >>> >>> Z Shell >>> .modules, .zshrc, .zshenv and .zlogin >>> >>> Friendly Interactive Shell >>> .modules, .config/fish/config.fish >>> >>> If a module load line is found in any of these files, the >>> mod- >>> ulefiles are appended to any existing list of >>> modulefiles. The >>> module load line must be located in at least one of the >>> files >>> listed above for any of the init sub-commands to work >>> properly. >>> If the module load line is found in multiple shell >>> initializa- >>> tion files, all of the lines are changed. >>> >>> >>> Note, the man page does not specify how the .modules file is used (I >>> suspect it is specifically used by the module command - not by the shell, >>> but when I am not sure). >>> The libexec/modulecmd.tcl file doesn't seem to directly use it (only >>> modifies it, if there). >>> >>> >>> On 2022-06-02 10:09 AM, Pierre Girard wrote: >>> >>> De : Jason Edgecombe <jwe...@un...> >>> I just realized that I didn't explain my problem very well. I'm looking >>> for how to split each user's automatically-loaded modules for each OS. In >>> other words, if I run "module initadd foo" on Ubuntu then the foo module >>> will be automatically loaded on Ubuntu, but not RHEL. >>> So if I understand correctly, you have 2 sets of modules that differ >>> depending on the OS. So having module load foo in the configuration file >>> would work on ubuntu and an error on RHEL or something along those lines. >>> Maybe write the module itself so it adjusts to the platform you’re on? >>> Something like this: >>> switch $env(DISTRO) { >>> ubuntu { >>> # do something >>> } >>> rhel { >>> # do something else >>> } >>> default { >>> # unknown system >>> } >>> } >>> On Thu, Jun 2, 2022 at 10:18 AM Pierre Girard <pie...@ge...< >>> mailto:pie...@ge... <pie...@ge...>>> wrote: >>> [Caution: Email from External Sender. Do not click or open links or >>> attachments unless you know this sender.] >>> De : Jason Edgecombe <jwe...@un...<mailto:jwe...@un... >>> <jwe...@un...>>> >>> Envoyé : 2 juin 2022 09:34 >>> À : mod...@li...< >>> mailto:mod...@li... >>> <mod...@li...>> >>> Objet : [Modules] modules on different Linux distros with shared NFS >>> home directories >>> I want to start using modules in our Linux environment. I support both >>> RHEL and Ubuntu machines that use the same shared NFS path for each user's >>> home directory. Is there a way for me to override the ~/.modules path to >>> make it something like ~/.modules-$DISTRO ? I would prefer to not modify >>> the core modulecmd.tcl file. I tried using trace commands in my site >>> config, but I can't seem to trace the cmdModuleInit procedure to override >>> things. >>> You should be able to change MODULEPATH environment variable. >>> export MODULEPATH=~/modulefiles:/home/modules/modulefiles-$DISTRO >>> _______________________________________________ >>> Modules-interest mailing list >>> Mod...@li...< >>> mailto:Mod...@li... >>> <Mod...@li...>> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest >>> _______________________________________________ >>> Modules-interest mailing list >>> Mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/modules-interest >>> >>> >>> -- >>> -------------------------------------------------------- >>> The views and opinions expressed above are strictly >>> those of the author(s). The content of this message has >>> not been reviewed nor approved by any entity whatsoever. >>> -------------------------------------------------------- >>> Paul FM Info: http://paulfm.com/~paulfm/ >>> -------------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Modules-interest mailing list >>> Mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/modules-interest >>> >>> >>> _______________________________________________ >>> Modules-interest mailing list >>> Mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/modules-interest >>> >> _______________________________________________ >> Modules-interest mailing list >> Mod...@li... >> https://lists.sourceforge.net/lists/listinfo/modules-interest >> > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > |
