|
From: Erik P. <eri...@si...> - 2022-07-14 21:14:24
|
Thanks for the input! I will just import the module file into the container and use that to setup the environment. As was said, I would just end up reimplementing a lot of what modulecmd already does. That `module show` command is perfect for parsing my MODULE_BASE_DIR env var that is set in the file. I do have one problematic line that is in most of my files though. ``` # obtain operating system detection functions source [file dirname $ModulesCurrentModulefile]/../../os-detect.tc ``` And the `/../../os-detect.tc` part can be up or down n number of directories since it is it just a relative path and some modules are one, two or three deep. I don’t suppose there is some way to “disable” that line without programmatically removing it from the file no? > On Jul 14, 2022, at 11:45 AM, Sternberg, Michael G. via Modules-interest <mod...@li...> wrote: > > The Environment Modules approach and its command language are designed to solve this exact problem. The actual modulefile contents are a very concise way to (a) describe, (b) apply, and (c) revert such changes to environment variables [+ a bit more]. You can see the commands by inspection of the modulefile, or by running "module show modulename". > > – If by "shell loadable .env file" you mean solely and explicitly *setting* or *unsetting* variables to static values, you preclude prepend/append operations that are needed for most PATH-type variables. If you allow for variable *modification*, you essentially would have to re-implement what Modules does. > > – If you mean "source-able shell code", then why not have that code be "module load modulename", ensuring that modulefiles are properly provisioned and Environment Modules is initialized for the relevant shell's profile and rc-files? > > > With best regards, > -- > Michael Sternberg, Ph.D. > Principal Scientific Computing Administrator > Center for Nanoscale Materials > Argonne National Laboratory > > >> On Jul 14, 2022, at 13:06, Erik Parawell <eri...@si...> wrote: >> I have a use case where I need to figure out what changed in the environment from performing a `module load` and then export those changes to a shell loadable .env file. I have toyed with a couple ideas as listed below. But hopefully you guys might know of a easier path for me to take. >> >> 1) Creating a program to load the module and then extract the changes of the environment and save that to a file. >> 2) Importing the module file into the container and letting it do the rest. The caveat is that the module still needs to be loaded beforehand to read the MODULE_BASE_DIR env var we have in each module to determine where the squashfs file needs to be created from and where the mount point would need to be. >> 3) Hopefully there is something easier or more maintainable than what I have been thinking of. >> <Squashfs tools(2).png> > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest |
