|
From: Xavier D. <xav...@gm...> - 2022-04-06 06:35:34
|
Hi Martin, Le mar. 5 avr. 2022 à 19:24, Bloecker, Martin < Mar...@am...> a écrit : > Hi Xavier, > > > > Thanks for your reply. The solution you describe is basically what I was > referring to with my comment “…this can be made to work when defining the > virtual modules in the root .modulerc”. Unfortunately the definition of > ‘localized-software’ modules will (potentially) involve searching the file > system for appropriate bin directories. One would not want to perform such > an (costly) operation during every module command so placing the respective > module-virtual code snippets in modulepath/.modulerc is not really an > option. > > > > So I guess currently there really is no way to define modules from a > different ‘namespace’ than the one the .modulerc file is evaluated in. The > solution I’m thus currently looking at is to link > modulepath/localized-software to the directory modulepath/vendor/software > and then have code in modulepath/vendor/software/.modulerc to distinguish > in which ‘namespace’ the .modulerc file is being evaluated. > > > > If I understand correctly the current implementation of the module-virtual > command evaluates both module name and module path relative to the > directory of the .modulerc file (i.e. in which ‘namespace’ as I call it the > .modulerc file is evaluated). Due to this a module definition with > ‘relative’ module name (e.g. module-virtual /2.0 null in the example > below) is possible. I think it thus would be helpful if the module-virtual > command would issue warnings (or even errors) in case a virtual module is > defined for a different namespace than the one the .modulerc file is being > evaluated in. I.e. in my example below the following lines: > > module-virtual 1.0 null > > module-virtual software/3.0 null > > module-virtual localized-software/5.0 null > > module-virtual localized-software/6.0 $ref_module > > will not work and thus should all yield such warnings/errors. Would that > be possible? > Could be possible to add such warning, and also for module-version and module-alias commands. This could be done when changing major version (6.0), so it is not something that will be implemented immediately. Also errors and warnings are silenced during "module avail", for a small mistake made by an admin not to break the output of all users. > > > Another question: > > When processing modulepath/.modulerc is there a way to known the namespace > for which a module is being searched? E.g. when issuing the command > “module avail localized-software” is there a way to know (in > modulepath/.modulerc) that all ‘localized-software’ modules are being > searched? > There is no way to know such thing during a search. This is especially tricky as "module avail loc", "module avail -C lized" or "module avail localized-sofware@:1+foo" will also trigger the evaluation of localized-software modulefiles. Best regards, Xavier > > > Best Regards, > > > > Martin > > > > *From:* Xavier Delaruelle <xav...@gm...> > *Sent:* Dienstag, 5. April 2022 07:19 > *To:* Environment Modules usage and discussion. < > mod...@li...> > *Subject:* Re: [Modules] Get list of available (virtual) modules from > within .modulerc > > > > *[---EXTERNAL---] * > > > > Hi Martin, > > > > When trying to load "localized-sofware", module evaluates: > > > > * modulepath/.modulerc > > * everything under modulepath/localized-sofware > > > > So in your example, it cannot find any localized-software modules as they > are defined under modulepath/software/vendor. > > > > One way to solve this, may be to source in modulepath/.modulerc any code > snippet found under the modulepath/software/vendor directories to execute > the module-virtual commands from the global .modulerc file of the > modulepath. > > > > Best regards, > > Xavier > > > > Le lun. 4 avr. 2022 à 15:11, Bloecker, Martin < > Mar...@am...> a écrit : > > Hi Xavier and Mailing List Members, > > > > Following your advice I’m now trying to set up virtual modules for the two > namespaces ‘vendor/software’ and ‘localized-software’. As mentioned earlier > we want modules to be maintained in self-contained software-specific > directories and thus would want to define these virtual modules in the same > .modulerc file (e.g. $MODULEPATH/vendor/software/.modulerc). The example > below demonstrates the current behavior. It references a copy of the ‘null’ > module file that comes with the modules installation: > > > > #%Module4.7 > > # vim: set tabstop=4 expandtab shiftwidth=4 textwidth=80 wrapmargin=5 : > > > > # $MODULEPATH/vendor/software/.modulerc > > # module module > > # avail? loadable? > comment > > > > module-virtual 1.0 null # no no no > error message > > module-virtual /2.0 null # yes yes > loads vendor/software/2.0 > > module-virtual software/3.0 null # no no no > error message > > module-virtual vendor/software/4.0 null # yes yes no > error message > > > > module-virtual localized-software/5.0 null # yes no no > error message > > > > # command below defines module 'localized-software/6.0' > > set ref_module [file join [ file dirname [ file normalize [ info script ] > ] ] null] > > module-virtual localized-software/6.0 $ref_module > > null # yes no no > error message > > > > The problem we encounter is that the virtual ‘localized-software’ modules > are defined (i.e. are displayed by module avail) but cannot be loaded. In > either case (relative or absolute module path definition) both > > module load localized-software/5.0 > > and > > module load localized-software/6.0 > > result in the error > > ERROR: Unable to locate a modulefile for 'localized-software' > > > > I know that this can be made to work when defining the virtual modules in > the root .modulerc file but as mentioned above I’m looking for a > ‘self-contained’ solution where all required module related code is under > the same subdirectory. Is this possible somehow? If not: Shouldn’t parsing > the .modulerc file issue a WARNING that virtual modules are being defined > that later on will not/cannot be found? > > > > Best Regards, > > > > Martin > > _______________________________________________ > 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 > |
