It may also be useful to only look at files with certain extensions.
And - at the same time, automatically look for some of those extensions when using the modules.
(these might be different options, with different lists of extensions)
Example, if the extension was .modfl
and you had this module file $MODULEPATH/test/junk.1.3.4.modfl
These module commands would be valid:
module load test/junk.1.3.4
or
module load test/junk.1.3.4.modfl
And when showing loaded modules, maybe omit the specified extensions (to cut down clutter).
And interesting side case would be, what if the extensions were: .modfl and .mod
and you had test.mod and test.modfl
Which module would be loaded by:
module load test
A side thought is with this, you could easily have "hidden" modules.
For instance, if the search list were .modfl
But the auto list was .modfl and .modhide
You could have a module:
test.modhide
That would not show up in: module avail
But could be loaded with: module load test
On 2025-01-17 7:25 AM, Bloecker, Martin wrote:
> Hello Xavier,
>
> from your summary below it is not clear to me if your proposed 'modulepath-only' and 'modulepath-ignore' commands would solely work in modifying the modulepath or if they would work on a per file level (e.g. to exclude certain file types from being considered modulefiles).
>
> The use case I was hoping to address with the new feature is the following: For the sake of modularity we have some files in module directories that are e.g. read by modulefiles but which are not valid modulefiles themselves. Currently these are hidden files (i.e. their name starting with a dot, e.g. '.some_function.tcl') so that the module command does not 'see' them.
>
> When managing the module directory tree these hidden files sometimes cause confusion. If we were able to define a modulefile name filter (e.g. ignore all *.tcl files) we could make such files regular files w/o any impact on the traversing of the modulepath. Hence the idea of using the gitignore syntax as this would enable ignoring both (classes of) files as well as directories. Or explicitly including them via negation.
>
> Best Regards,
>
> Martin--
--------------------------------------------------------
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/
--------------------------------------------------------
|