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?
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?
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...<mailto: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...<mailto:Mod...@li...>
https://lists.sourceforge.net/lists/listinfo/modules-interest
|