|
From: Bloecker, M. <Mar...@am...> - 2022-04-07 17:04:06
|
Hi Xavier,
Please see my comment below.
Regards,
Martin
From: Xavier Delaruelle <xav...@gm...>
Sent: Mittwoch, 6. April 2022 08:35
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Get list of available (virtual) modules from within .modulerc
Hi Martin,
Le mar. 5 avr. 2022 à 19:24, Bloecker, Martin <Mar...@am...<mailto: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.
[MB] The behavior of silencing errors/warnings during a “module avail” certainly should remain. The bigger problem from my perspective is that module avail currently does show such “ill-defined” modules as available. It would be best if “ill-defined” modules would not show up as available modules at all. Currently trying to load such an “ill-defined” module results in an error message (“Unable to locate a modulefile for …” that makes it hard to debug the problem mainly because the “module-virtual” command is syntactically correct and (with respect to the .modulerc file where it is defined) also seems to be semantically correct.
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...<mailto:xav...@gm...>>
Sent: Dienstag, 5. April 2022 07:19
To: Environment Modules usage and discussion. <mod...@li...<mailto: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
_______________________________________________
Modules-interest mailing list
Mod...@li...<mailto:Mod...@li...>
https://lists.sourceforge.net/lists/listinfo/modules-interest
|
