modules-interest — Discussion forum for modules usage.

Re: [Modules] Sticky modules message without error

[Xavier D. <xav...@gm...>]

An error is raised as purge should result in an empty loaded module list.

I understand that this behavior could disturb some users.

So a configuration option may be introduced to define the expected
behavior. I have created an issue ticket for this feature request:
https://github.com/cea-hpc/modules/issues/502

Best regards,
Xavier

Le lun. 26 juin 2023 à 16:04, Adrien COTTE - Groupe EOLEN
<adr...@eo...> a écrit :
>
> Of course.
>
> Let's take a module "slurm/22.05.7".
> This module is loaded at the login and has the super-sticky tag.
>
> I mean, each user must have this module loaded, otherwise they cannot run any job.
>
> After loaded several other modules, my users want to clean their env with "module purge".
>
> But, this message (with verbosity concise) appears:
>
> Unloading slurm/22.05.7
>     Error: Unload of sticky module skipped
>
> And $? is 1.
>
> When I explain to my users why there is this message,  they say "ok, so this is normal and not an error". It's hard to disagree, this is the right behaviour. It should be a simple INFO, a Warning at least, but not an Error.
>
> Is it more clear?
>
> Thx,
> Adrien
> ________________________________
> From: Xav...@CE... <Xav...@CE...>
> Sent: Monday, June 26, 2023 11:13:22 AM
> To: mod...@li... <mod...@li...>
> Subject: Re: [Modules] Sticky modules message without error
>
> Hi Adrien,
>
> Could you please give some details in what situations these messages are obtained and scare users.
>
> Best regards,
> Xavier
>
> On Mon, 2023-06-26 at 08:39 +0000, Adrien COTTE - Groupe EOLEN wrote:
>
> Hi,
>
> I've set some modules as Sticky, but my users are scared about the Error message.
>
> Is there any way to transform this message into Warning and not return code 1?
>
> Best,
> Adrien
>
> _______________________________________________
>
> 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

[Modules] source-sh without exporting functions

[Bhargav K. <bk...@mi...>]

Micron Confidential

Hi Team,
I am trying to source an externally managed bash script using 'source-sh' command in a module file.
But it also exports functions defined in that file, while I am interested only in environment variables.
I can try 'unset-function' but it's hard to keep track of function definition changes.

How to achieve this.

--
Bhargav



Micron Confidential

Re: [Modules] Sticky modules message without error

[Adrien C. - G. E. <adr...@eo...>]

Of course.

Let's take a module "slurm/22.05.7".
This module is loaded at the login and has the super-sticky tag.

I mean, each user must have this module loaded, otherwise they cannot run any job.

After loaded several other modules, my users want to clean their env with "module purge".

But, this message (with verbosity concise) appears:

Unloading slurm/22.05.7
    Error: Unload of sticky module skipped

And $? is 1.

When I explain to my users why there is this message,  they say "ok, so this is normal and not an error". It's hard to disagree, this is the right behaviour. It should be a simple INFO, a Warning at least, but not an Error.

Is it more clear?

Thx,
Adrien
________________________________
From: Xav...@CE... <Xav...@CE...>
Sent: Monday, June 26, 2023 11:13:22 AM
To: mod...@li... <mod...@li...>
Subject: Re: [Modules] Sticky modules message without error

Hi Adrien,

Could you please give some details in what situations these messages are obtained and scare users.

Best regards,
Xavier

On Mon, 2023-06-26 at 08:39 +0000, Adrien COTTE - Groupe EOLEN wrote:
Hi,

I've set some modules as Sticky, but my users are scared about the Error message.

Is there any way to transform this message into Warning and not return code 1?

Best,
Adrien

_______________________________________________

Modules-interest mailing list

<mailto:Mod...@li...>

Mod...@li...


<https://lists.sourceforge.net/lists/listinfo/modules-interest>

https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Sticky modules message without error

[<Xav...@CE...>]

Hi Adrien,

Could you please give some details in what situations these messages are obtained and scare users.

Best regards,
Xavier

On Mon, 2023-06-26 at 08:39 +0000, Adrien COTTE - Groupe EOLEN wrote:
Hi,

I've set some modules as Sticky, but my users are scared about the Error message.

Is there any way to transform this message into Warning and not return code 1?

Best,
Adrien

_______________________________________________

Modules-interest mailing list

<mailto:Mod...@li...>

Mod...@li...


<https://lists.sourceforge.net/lists/listinfo/modules-interest>

https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Sticky modules message without error

[Adrien C. - G. E. <adr...@eo...>]

Hi,

I've set some modules as Sticky, but my users are scared about the Error message.

Is there any way to transform this message into Warning and not return code 1?

Best,
Adrien

Re: [Modules] When the version string naturally contains the variant delimiter "+"

[Xavier D. <xav...@gm...>]

Hi Martin,

I would suggest to disable the advanced_version_spec configuration
option [1] as your module names are not compatible with the variant
specification syntax.

module config advanced_version_spec 0

This command could be set in global initrc file [2]

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/module.html#mconfig-advanced_version_spec
[2] https://modules.readthedocs.io/en/latest/INSTALL.html#configuration

Le mar. 20 juin 2023 à 20:15, D'Anjou, Martin via Modules-interest
<mod...@li...> a écrit :
>
> Hi,
>
>
>
> I am trying to upgrade environment modules and I am running into an issue with the variant feature.
>
> Java version strings contain the “+” plus sign, for example: openjdk-hs-17.0.1+12
>
>
>
> When I load it with --debug, I get:
>
> DEBUG setModuleVersSpec: Set module 'openjdk-hs/17.0.1' (escglob 'openjdk-hs/17.0.1'),  module name 'openjdk-hs' (re ''), module root 'openjdk-hs', version cmp 'eq', version(s) '', variant(s) '{12 1 1}' and module name version spec 'openjdk-hs/17.0.1' for argument 'openjdk-hs/17.0.1+12'
>
> ..
>
> ERROR: Unable to locate a modulefile for 'openjdk-hs/17.0.1+12'
>
>
>
> I can see the file exists and load just fine with the older version of modules, but not when I upgrade to 5.0.1.
>
>
>
> In the code, I see the split on the “+” sign happening in modules/tcl/modspec.tcl/setModuleVersSpec line 1561, so it looks baked in and unavoidable.
>
>
>
> I am trying to avoid any disruption to the users, does anyone have advice on how to approach this problem?
>
> Or maybe add something non-disturbing to my existing installation so the upgrade could be seamless, and my users would not have to modify their code?
>
>
>
> Thanks,
>
> Martin
>
>
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] When the version string naturally contains the variant delimiter "+"

[D'Anjou, M. <md...@ci...>]

Hi,

I am trying to upgrade environment modules and I am running into an issue with the variant feature.
Java version strings contain the "+" plus sign, for example: openjdk-hs-17.0.1+12

When I load it with --debug, I get:
DEBUG setModuleVersSpec: Set module 'openjdk-hs/17.0.1' (escglob 'openjdk-hs/17.0.1'),  module name 'openjdk-hs' (re ''), module root 'openjdk-hs', version cmp 'eq', version(s) '', variant(s) '{12 1 1}' and module name version spec 'openjdk-hs/17.0.1' for argument 'openjdk-hs/17.0.1+12'
..
ERROR: Unable to locate a modulefile for 'openjdk-hs/17.0.1+12'

I can see the file exists and load just fine with the older version of modules, but not when I upgrade to 5.0.1.

In the code, I see the split on the "+" sign happening in modules/tcl/modspec.tcl/setModuleVersSpec line 1561<https://github.com/cea-hpc/modules/blob/48eeb0873014a033791194b99a6521b5daee794d/tcl/modspec.tcl#L1561>, so it looks baked in and unavoidable.

I am trying to avoid any disruption to the users, does anyone have advice on how to approach this problem?
Or maybe add something non-disturbing to my existing installation so the upgrade could be seamless, and my users would not have to modify their code?

Thanks,
Martin

Re: [Modules] Modules 5.3.0 relaeased

[<sys...@ro...>]

Hello Xavier,
Thank you very much for this fabulous reading with the new update.

I installed this release today on my two clusters using the GNU-C 13.1 compiler and my first impression is that it has become incredibly fast. I will have a look at the new features and give you a feedback afterwards.

Best regards from Berlin

Z. Matthias

> On Montag, Mai 15, 2023 at 6:51 AM, Xavier Delaruelle <xav...@gm... (mailto:xav...@gm...)> wrote:
> Hello All,
>
> Modules 5.3 is out! As usual this new version comes with many new
> features: Module cache, Querying available module variants, Extra
> specifiers, Append or subtract elements to current option value.
>
> Details on the major changes included in this new release are provided
> in the MIGRATING document. The list of all changes made in this new
> version are described in the NEWS document.
>
> http://modules.readthedocs.io/en/stable/MIGRATING.html
> http://modules.readthedocs.io/en/stable/NEWS.html
>
> The tarball of this new version can be downloaded at:
>
> http://downloads.sourceforge.net/modules/modules-5.3.0.tar.gz
>
> The zipball to install this new version on Windows platform can be
> downloaded at:
>
> http://downloads.sourceforge.net/modules/modules-5.3.0-win.zip
>
> If you encounter any issue, please let us know by creating a ticket on
> the project bug tracker at:
>
> https://github.com/cea-hpc/modules/issues
>
> Many thanks to all of you who improve Modules by reporting bugs or
> sharing new ideas.
>
> Best regards,
> Xavier
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

[Modules] Modules 5.3.0 relaeased

[Xavier D. <xav...@gm...>]

Hello All,

Modules 5.3 is out! As usual this new version comes with many new
features: Module cache, Querying available module variants, Extra
specifiers, Append or subtract elements to current option value.

Details on the major changes included in this new release are provided
in the MIGRATING document. The list of all changes made in this new
version are described in the NEWS document.

 http://modules.readthedocs.io/en/stable/MIGRATING.html
 http://modules.readthedocs.io/en/stable/NEWS.html

The tarball of this new version can be downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.3.0.tar.gz

The zipball to install this new version on Windows platform can be
downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.3.0-win.zip

If you encounter any issue, please let us know by creating a ticket on
the project bug tracker at:

 https://github.com/cea-hpc/modules/issues

Many thanks to all of you who improve Modules by reporting bugs or
sharing new ideas.

Best regards,
Xavier

[Modules] Append or subtract elements to current option value

[Xavier D. <xav...@gm...>]

Hello All,

Last feature addition for upcoming v5.3: ability to append or subtract
elements to current option value.

For command-line switches and configuration options whose value is a
colon-separated list, using value prefixed by + or - respectively
append or subtract the value to the existing one.

See details and examples at:
https://modules.readthedocs.io/en/latest/MIGRATING.html#append-or-subtract-elements-to-current-option-value

Regards,
Xavier

[Modules] Extra specifiers

[Xavier D. <xav...@gm...>]

Hello All,

New feature unveil for next version (5.3): Extra specifiers.

Extra specifiers can be specified with element:name syntax as part of
module specification on module search commands (avail, paths and and
whatis).

With them it is possible for instance to list available modules
modifying a given environment variable or requiring a given module.

See details and examples at:
https://modules.readthedocs.io/en/latest/MIGRATING.html#extra-specifiers

Regards,
Xavier

[Modules] Querying available module variants

[Xavier D. <xav...@gm...>]

Hello All,

I would like to highlight a new feature for next version (5.3):
ability to query available module variants and their value.

A new mechanism named Extra match search is introduced to evaluate
modulefiles during a module search to find those matching an extra
query on a variant value, a dependency or an environment variable
definition.

During this specific evaluation, modulefiles are interpreted in scan
mode to collect the different Tcl modulefile commands they use.

With this new mechanism, it is possible to list all available variant
defined in modulefiles with their associated values. You can also
search for modules defining a specific variant value.

See examples at:

https://modules.readthedocs.io/en/latest/MIGRATING.html#querying-available-module-variants

Regards,
Xavier

Re: [Modules] "module load" compatibility

[Sternberg, M. G. <ste...@an...>]

Danny,

If you are absolutely set on having PATH be carried over unconditionally from the submitting environment onto your compute nodes, then on them add this at a suitable stage of their shell init:

	test -n "$PBS_O_PATH" && PATH=$PBS_O_PATH

I don't, however, recommended such bulldozing on a general-purpose HPC machine.


With best regards,
Michael


> On Apr 23, 2023, at 13:38, Danny Sternkopf <Dan...@EM...> wrote:
> Hi Michael,
> thank you for helping out! We did already figure out that our workload manager(which is not PBS) simply ignores PATH when exporting is enabled. We‘re already in touch with the vendor(us;-)).
> Best regards,
> Danny
> …
> 
> On 4/23/2023 11:53 AM, Sternberg, Michael G. via Modules-interest wrote:
> > Danny, 
> > To diagnose where PATH takes an unexpected turn on a test execution node, temporarily add to /etc/profile or a subordinate file:
> > 
> > 	test -n "$PBS_JOBID" && set -x
> > 
> > Results will land in stderr of a test job that you have PBS run there. Don't forget to undo the above.
> > 
> > The "#PBS -V" directive is a rather blunt instrument to carry over env. vars from the submission node to the job execution node (and the first one only at that). The env. may contain state variables from the submission node that are irrelevant or misleading on the execution node. Preferable would be loading modules per the system and user's shell dotfiles, or if needed to vary by job then by "module load …" commands in the job script itself, preceding the main application command.

Re: [Modules] "module load" compatibility

[Danny S. <Dan...@EM...>]

Hi Michael,

thank you for helping out! We did already figure out that our workload manager(which is not PBS) simply ignores PATH when exporting is enabled. We‘re already in touch with the vendor(us;-)).

Best regards,
Danny

Gesendet von Outlook für iOS<https://aka.ms/o0ukef>
________________________________
Von: Paul Markfort <pau...@gm...>
Gesendet: Sunday, April 23, 2023 8:10:06 PM
An: mod...@li... <mod...@li...>
Betreff: Re: [Modules] "module load" compatibility

Another use of reloading a module (effectively unload+load), is to make sure a path component is either at the end or start of the path (assuming it was originally added by that module). A good example is that base/dot module I have. NOTE: 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltOJvky9tLhRT6N6sshjSQgycfo4YypYTOepjVPKAraY4qm5pKqXTgfoUq33tJ07fUyu6w9VsMb1gUSqZUnfO2a4JqacI91PEqUbMM$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd

Another use of reloading a module (effectively unload+load), is to make sure a path component is either at the end or start of the path (assuming it was originally added by that module).

A good example is that base/dot module I have.
NOTE: (having dealt with windows for years) I prefer that "." (the current directory) NOT be in the path.

I use remove-path, in case . is already in the path; to guarantee that . is at the end of the path (the only place it should be if you put it in the path - In Windows/DOS: it is assumed at the start of the path, even if not there).

It is simply:

------------------ START ----
#%Module1.0

proc ModulesHelp { } {
         puts stderr "Provides path support for . "
}

# Make sure it is put at the end
remove-path PATH "."
append-path PATH "."
------------------ END ------

I note, that a quick test with "Modules Release 5.2.0 (2022-11-08" points out an interesting behavior (that you should be aware of when using remove-path).

I first put . in the front of the path with:
PATH=".:$PATH"
Then "module load base/dot" - works as expected (. moves to the end).
Then "module unload base/dot" - and it does an unexpected (but not a bad thing):
It removes . from the path (I was expecting it to restore it to the front).

This is properly and fully documented in: man modulefile
(you can change this behavior) - so it is not a bug, nor does the default unload action of remove-path need to be changed (just unexpected, unless you read the man page thoroughly).





On 4/23/2023 11:53 AM, Sternberg, Michael G. via Modules-interest wrote:
> Danny,
>
> To diagnose where PATH takes an unexpected turn on a test execution node, temporarily add to /etc/profile or a subordinate file:
>
>       test -n "$PBS_JOBID" && set -x
>
> Results will land in stderr of a test job that you have PBS run there. Don't forget to undo the above.
>
> The "#PBS -V" directive is a rather blunt instrument to carry over env. vars from the submission node to the job execution node (and the first one only at that). The env. may contain state variables from the submission node that are irrelevant or misleading on the execution node. Preferable would be loading modules per the system and user's shell dotfiles, or if needed to vary by job then by "module load …" commands in the job script itself, preceding the main application command.
>
>
>
> With best regards,
>

--
--------------------------------------------------------
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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!mSTkUSX2MK5sAHVOIZz9UODcS4SEbCWY0LaOf7R1fLgm55W23YE2vGoYYi18993VewzCF_Sjl-_Gask9VZV1ZSQS$[paulfm[.]com]
--------------------------------------------------------


_______________________________________________
Modules-interest mailing list
Mod...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!mSTkUSX2MK5sAHVOIZz9UODcS4SEbCWY0LaOf7R1fLgm55W23YE2vGoYYi18993VewzCF_Sjl-_Gask9VawtpOwF$[lists[.]sourceforge[.]net]

Re: [Modules] "module load" compatibility

[Paul M. <pau...@gm...>]

Another use of reloading a module (effectively unload+load), is to make sure a path component is either at the end or start of the path (assuming it was originally added by that module).

A good example is that base/dot module I have.
NOTE: (having dealt with windows for years) I prefer that "." (the current directory) NOT be in the path.

I use remove-path, in case . is already in the path; to guarantee that . is at the end of the path (the only place it should be if you put it in the path - In Windows/DOS: it is assumed at the start of the path, even if not there).

It is simply:

------------------ START ----
#%Module1.0

proc ModulesHelp { } {
         puts stderr "Provides path support for . "
}

# Make sure it is put at the end
remove-path PATH "."
append-path PATH "."
------------------ END ------

I note, that a quick test with "Modules Release 5.2.0 (2022-11-08" points out an interesting behavior (that you should be aware of when using remove-path).

I first put . in the front of the path with:
PATH=".:$PATH"
Then "module load base/dot" - works as expected (. moves to the end).
Then "module unload base/dot" - and it does an unexpected (but not a bad thing):
It removes . from the path (I was expecting it to restore it to the front).

This is properly and fully documented in: man modulefile
(you can change this behavior) - so it is not a bug, nor does the default unload action of remove-path need to be changed (just unexpected, unless you read the man page thoroughly).





On 4/23/2023 11:53 AM, Sternberg, Michael G. via Modules-interest wrote:
> Danny,
> 
> To diagnose where PATH takes an unexpected turn on a test execution node, temporarily add to /etc/profile or a subordinate file:
> 
> 	test -n "$PBS_JOBID" && set -x
> 
> Results will land in stderr of a test job that you have PBS run there. Don't forget to undo the above.
> 
> The "#PBS -V" directive is a rather blunt instrument to carry over env. vars from the submission node to the job execution node (and the first one only at that). The env. may contain state variables from the submission node that are irrelevant or misleading on the execution node. Preferable would be loading modules per the system and user's shell dotfiles, or if needed to vary by job then by "module load …" commands in the job script itself, preceding the main application command.
> 
> 
> 
> With best regards,
> 

-- 
--------------------------------------------------------
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/
--------------------------------------------------------

Re: [Modules] "module load" compatibility

[Sternberg, M. G. <ste...@an...>]

Danny,

To diagnose where PATH takes an unexpected turn on a test execution node, temporarily add to /etc/profile or a subordinate file:

	test -n "$PBS_JOBID" && set -x

Results will land in stderr of a test job that you have PBS run there. Don't forget to undo the above.

The "#PBS -V" directive is a rather blunt instrument to carry over env. vars from the submission node to the job execution node (and the first one only at that). The env. may contain state variables from the submission node that are irrelevant or misleading on the execution node. Preferable would be loading modules per the system and user's shell dotfiles, or if needed to vary by job then by "module load …" commands in the job script itself, preceding the main application command.



With best regards,
-- 
Michael Sternberg, Ph.D.
Principal Scientific Computing Administrator
Center for Nanoscale Materials
Argonne National Laboratory



> On Apr 23, 2023, at 01:13, Danny Sternkopf <Dan...@em...> wrote:
> Hi Xavier,
> in our case we have (workload manager) feature to export/transport all environment variables from the submit to the execution host (PBS # -V). It works except for PATH which gets overwritten by something very minimal. We don’t know why (yet), but this is not our topic here. Also it’s a very dangerous feature with high potential of messing up things completely. 
> 
> For module it means LOADEDMODULES  u. _LMFILES_ as well as all other environment variables besides PATH are still intact. The system profile mechanism gets started (after that) and is trying to load the default modules (which doesn’t work for 4.x anymore):
> … 
> 
>> Le ven. 21 avr. 2023 à 20:15, Danny Sternkopf <Dan...@em...> a écrit :
>> 
>> …
>> Basically what we want is to ‘semi-recover’ from a situation where only PATH is messed up (without going into details).
>> 
>> So we just load the system default modules again to have at least a good enough environment.

Re: [Modules] "module load" compatibility

[Danny S. <Dan...@EM...>]

Hi Xavier,

in our case we have (workload manager) feature to export/transport all environment variables from the submit to the execution host (PBS # -V). It works except for PATH which gets overwritten by something very minimal. We don’t know why (yet), but this is not our topic here. Also it’s a very dangerous feature with high potential of messing up things completely.

For module it means LOADEDMODULES  u. _LMFILES_ as well as all other environment variables besides PATH are still intact. The system profile mechanism gets started (after that) and is trying to load the default modules (which doesn’t work for 4.x anymore):

module load abc
module load def
module load ghi

and so on.

The reload command is quite interesting because it would restore the exact same modules and module versions from the origin environment (when using the export feature of course). That would even improve the situation as we had with module 3.x. 😉

Of course loading the system defaults can cause conflicts, but that we had with module 3.x as well.

Thank you and Best regards,
Danny


From: Xavier Delaruelle <xav...@gm...>
Sent: 22 April 2023 07:31
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] "module load" compatibility

In the situation you describe, some modules are already loaded, their environment variable are set but shell alias and function vanished. This is typically the case when starting a subshell session. With Modules v4, you can "module reload"
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!1NtAYp1Rtx2EjfFl4uvPIt3W-snY2vc32OWylQR619ICJXrcURYvP5xA6-P-K8jVhvgL-8Iq0Qj_9rewUpjdt8egRvGCU_zKO9OkdGPC8kHQQghIMdBnKoTCXOxyxD4T6w$>   ‌
ZjQcmQRYFpfptBannerEnd
In the situation you describe, some modules are already loaded, their environment variable are set but shell alias and function vanished. This is typically the case when starting a subshell session.

With Modules v4, you can "module reload" to unload then load again all loaded modules.

Starting Modules v5, "module refresh" has been brought back and it is automatically triggered when initializing module in a subshell session [1]. So shell aliases and functions are still defined along their loaded module.

To answer Paul's question: loading again an already loaded module may be implemented in the future, yes.

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/MIGRATING.html#improving-modules-initialization [modules.readthedocs.io]<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/MIGRATING.html*improving-modules-initialization__;Iw!!BQNorrFsuw!m-v-yG0GvgoGV87KPO8n3tI7q3Py7WYuBmbKi1UgTIkfe15S6uQJa9geKrPVkzfi2xKBHT9Qm66JTTlxqDlTClCCRzwtQo_9$>

Le ven. 21 avr. 2023 à 20:15, Danny Sternkopf <Dan...@em...<mailto:Dan...@em...>> a écrit :
Hi Paul,

All right, I meant the base vs specific module file behaviour when using switch. And we use the base version only.

Okay, there are some drawbacks. But I think in our case we really want to load the default version.

Our use case a bit bizarre. 😉

Basically what we want is to ‘semi-recover’ from a situation where only PATH is messed up (without going into details).
So we just load the system default modules again to have at least a good enough environment.

Best regards,
Danny


From: Paul Markfort <pau...@gm...<mailto:pau...@gm...>>
Sent: 21 April 2023 17:02
To: mod...@li...<mailto:mod...@li...>
Subject: Re: [Modules] "module load" compatibility

Mine was just an example (the module I was using to test is actually call base/dot - it adds ". " to the path, at the end. base is a folder, and dot is the name of a module file in that folder). If you are loading a specific module file, I don't
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltERtMYvfPKBF6NwOHrzUHitsg8S3HQplZLb3Wu_8_i_X8Bm1zPtR6DCtQe3SHjp2cRqqJKnT01toJiNJRMEB1O-FAS45QBdyfsA58$>   ‌
ZjQcmQRYFpfptBannerEnd

Mine was just an example (the module I was using to test is actually call base/dot - it adds "." to the path, at the end. base is a folder, and dot is the name of a module file in that folder).



If you are loading a specific module file, I don't foresee a problem.

If base is a folder with multiple modules under it, then this could end up unloading another module under base (if the default module isn't already loaded).





On 4/21/2023 9:47 AM, Danny Sternkopf wrote:

> Hi Paul,

>

> Thank you for the advices!

>

> As we’re just using the base module for loading I tested

> ‘module switch base base’

>

> and it seems to work (module gets reloaded incl dependencies even if loaded already). This is what we want.

>

> Do you see any problem with it in comparison to the dot version ‘ module switch base/dot base/dot’ you recommended?

> Any other drawbacks?

>

> Best regards,

> Danny

>

> From: Paul Markfort <pau...@gm...<mailto:pau...@gm...>>

> Sent: 21 April 2023 16:15

> To: mod...@li...<mailto:mod...@li...>

> Subject: Re: [Modules] "module load" compatibility

>

> I suggest (if you can) that you update to: Modules Release 5. 2. 0 (2022-11-08) (has the same issue, but has many improvements and corrections). Try using "module switch" instead of module load. Note, you can only load one module with module

> ZjQcmQRYFpfptBannerStart

> This Message Is From an External Sender

> This message came from outside your organization.

>      Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltPJtMZlpNr756NSmphjamxzF7ZB1hr2Q-JeXQq2fj5Akb0iruOBqzqpwYmNVNmR5ZwDpgVelvBz8Eyc5ZCLiWq-JqhWgnxMfSddmU$>   ‌

> ZjQcmQRYFpfptBannerEnd

>

> I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)

>

> (has the same issue, but has many improvements and corrections).

>

>

>

> Try using "module switch" instead of module load.

>

> Note, you can only load one module with module switch.

>

>

>

> There are some issues with this.

>

> If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.

>

>

>

> A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).

>

>

>

> As in:

>

>    module switch base/dot base/dot

>

>

>

> However, you should see the previous post about "module load" behavior.

>

>

>

>

>

> Notes:

>

>

>

> This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).

>

>

>

> I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).

>

>

>

>

>

>

>

> On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:

>

>> Dear all,

>

>>

>

>> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://urldefense.com/v3/__https://modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$>[modules[.]readthedocs[.]io]<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3chttps:/urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3e%5bmodules%5b.%5dreadthedocs%5b.%5dio%5d>says

>

>>

>

>> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.

>

>>

>

>> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.

>

>>

>

>> Thank you and best regards,

>

>>

>

>> Jens-Olaf

>

>> ---

>

>> Dr. Jens-Olaf Beismann          Benchmarking Expert

>

>> High Performance Computing      NEC Deutschland GmbH     https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$>[nec[.]com]<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>

><https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>

>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)

>

>> ---

>

>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf

>

>> Geschäftsführer: Yuichi Kojima

>

>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

>

>>

>

>>

>

>> _______________________________________________

>

>> Modules-interest mailing list

>

>> Mod...@li...<mailto:Mod...@li...<mailto:Mod...@li...%3cmailto:Mod...@li...>>

>

>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

><https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

>>

>

>

>

> --

>

> --------------------------------------------------------

>

> 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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$>[paulfm[.]com]<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>

><https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>

> --------------------------------------------------------

>

>

>

>

>

> _______________________________________________

>

> Modules-interest mailing list

>

> Mod...@li...<mailto:Mod...@li...<mailto:Mod...@li...%3cmailto:Mod...@li...>>

>

> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

><https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

>

>

> _______________________________________________

> Modules-interest mailing list

> Mod...@li...<mailto:Mod...@li...>

> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]

>



--

--------------------------------------------------------

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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$>[paulfm[.]com]

--------------------------------------------------------





_______________________________________________

Modules-interest mailing list

Mod...@li...<mailto:Mod...@li...>

https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]
_______________________________________________
Modules-interest mailing list
Mod...@li...<mailto:Mod...@li...>
https://lists.sourceforge.net/lists/listinfo/modules-interest [lists.sourceforge.net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!m-v-yG0GvgoGV87KPO8n3tI7q3Py7WYuBmbKi1UgTIkfe15S6uQJa9geKrPVkzfi2xKBHT9Qm66JTTlxqDlTClCCR7imbY1k$>

Re: [Modules] "module load" compatibility

[Xavier D. <xav...@gm...>]

In the situation you describe, some modules are already loaded, their
environment variable are set but shell alias and function vanished. This is
typically the case when starting a subshell session.

With Modules v4, you can "module reload" to unload then load again all
loaded modules.

Starting Modules v5, "module refresh" has been brought back and it is
automatically triggered when initializing module in a subshell session [1].
So shell aliases and functions are still defined along their loaded module.

To answer Paul's question: loading again an already loaded module may be
implemented in the future, yes.

Regards,
Xavier

[1]
https://modules.readthedocs.io/en/latest/MIGRATING.html#improving-modules-initialization

Le ven. 21 avr. 2023 à 20:15, Danny Sternkopf <Dan...@em...>
a écrit :

> Hi Paul,
>
>
>
> All right, I meant the base vs specific module file behaviour when using
> switch. And we use the base version only.
>
>
>
> Okay, there are some drawbacks. But I think in our case we really want to
> load the default version.
>
>
>
> Our use case a bit bizarre. 😉
>
>
>
> Basically what we want is to ‘semi-recover’ from a situation where only
> PATH is messed up (without going into details).
>
> So we just load the system default modules again to have at least a good
> enough environment.
>
>
>
> Best regards,
>
> Danny
>
>
>
>
>
> *From:* Paul Markfort <pau...@gm...>
> *Sent:* 21 April 2023 17:02
> *To:* mod...@li...
> *Subject:* Re: [Modules] "module load" compatibility
>
>
>
> Mine was just an example (the module I was using to test is actually call
> base/dot - it adds ". " to the path, at the end. base is a folder, and dot
> is the name of a module file in that folder). If you are loading a specific
> module file, I don't
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> This message came from outside your organization.
>
>   *  Report Suspicious  *
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltERtMYvfPKBF6NwOHrzUHitsg8S3HQplZLb3Wu_8_i_X8Bm1zPtR6DCtQe3SHjp2cRqqJKnT01toJiNJRMEB1O-FAS45QBdyfsA58$>  ‌
>
>
> ZjQcmQRYFpfptBannerEnd
>
> Mine was just an example (the module I was using to test is actually call base/dot - it adds "." to the path, at the end. base is a folder, and dot is the name of a module file in that folder).
>
>
>
> If you are loading a specific module file, I don't foresee a problem.
>
> If base is a folder with multiple modules under it, then this could end up unloading another module under base (if the default module isn't already loaded).
>
>
>
>
>
> On 4/21/2023 9:47 AM, Danny Sternkopf wrote:
>
> > Hi Paul,
>
> >
>
> > Thank you for the advices!
>
> >
>
> > As we’re just using the base module for loading I tested
>
> > ‘module switch base base’
>
> >
>
> > and it seems to work (module gets reloaded incl dependencies even if loaded already). This is what we want.
>
> >
>
> > Do you see any problem with it in comparison to the dot version ‘ module switch base/dot base/dot’ you recommended?
>
> > Any other drawbacks?
>
> >
>
> > Best regards,
>
> > Danny
>
> >
>
> > From: Paul Markfort <pau...@gm...>
>
> > Sent: 21 April 2023 16:15
>
> > To: mod...@li...
>
> > Subject: Re: [Modules] "module load" compatibility
>
> >
>
> > I suggest (if you can) that you update to: Modules Release 5. 2. 0 (2022-11-08) (has the same issue, but has many improvements and corrections). Try using "module switch" instead of module load. Note, you can only load one module with module
>
> > ZjQcmQRYFpfptBannerStart
>
> > This Message Is From an External Sender
>
> > This message came from outside your organization.
>
> >      Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltPJtMZlpNr756NSmphjamxzF7ZB1hr2Q-JeXQq2fj5Akb0iruOBqzqpwYmNVNmR5ZwDpgVelvBz8Eyc5ZCLiWq-JqhWgnxMfSddmU$>   ‌
>
> > ZjQcmQRYFpfptBannerEnd
>
> >
>
> > I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)
>
> >
>
> > (has the same issue, but has many improvements and corrections).
>
> >
>
> >
>
> >
>
> > Try using "module switch" instead of module load.
>
> >
>
> > Note, you can only load one module with module switch.
>
> >
>
> >
>
> >
>
> > There are some issues with this.
>
> >
>
> > If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.
>
> >
>
> >
>
> >
>
> > A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).
>
> >
>
> >
>
> >
>
> > As in:
>
> >
>
> >    module switch base/dot base/dot
>
> >
>
> >
>
> >
>
> > However, you should see the previous post about "module load" behavior.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Notes:
>
> >
>
> >
>
> >
>
> > This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).
>
> >
>
> >
>
> >
>
> > I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:
>
> >
>
> >> Dear all,
>
> >
>
> >>
>
> >
>
> >> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://urldefense.com/v3/__https://modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$>[modules[.]readthedocs[.]io] <https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3chttps:/urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3e%5bmodules%5b.%5dreadthedocs%5b.%5dio%5d>says
>
> >
>
> >>
>
> >
>
> >> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.
>
> >
>
> >>
>
> >
>
> >> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.
>
> >
>
> >>
>
> >
>
> >> Thank you and best regards,
>
> >
>
> >>
>
> >
>
> >> Jens-Olaf
>
> >
>
> >> ---
>
> >
>
> >> Dr. Jens-Olaf Beismann          Benchmarking Expert
>
> >
>
> >> High Performance Computing      NEC Deutschland GmbH     https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$>[nec[.]com] <https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>
>
> > <https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>
>
> >> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
>
> >
>
> >> ---
>
> >
>
> >> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
>
> >
>
> >> Geschäftsführer: Yuichi Kojima
>
> >
>
> >> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
>
> >
>
> >>
>
> >
>
> >>
>
> >
>
> >> _______________________________________________
>
> >
>
> >> Modules-interest mailing list
>
> >
>
> >> Mod...@li...<mailto:Mod...@li...>
>
> >
>
> >> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net] <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>
>
> > <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>
>
> >>
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > --------------------------------------------------------
>
> >
>
> > 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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$>[paulfm[.]com] <https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>
>
> > <https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>
>
> > --------------------------------------------------------
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> >
>
> > Modules-interest mailing list
>
> >
>
> > Mod...@li...<mailto:Mod...@li...>
>
> >
>
> > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net] <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>
>
> > <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>
>
> >
>
> >
>
> > _______________________________________________
>
> > Modules-interest mailing list
>
> > Mod...@li...
>
> > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$ <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]
>
> >
>
>
>
> --
>
> --------------------------------------------------------
>
> 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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$ <https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$>[paulfm[.]com]
>
> --------------------------------------------------------
>
>
>
>
>
> _______________________________________________
>
> Modules-interest mailing list
>
> Mod...@li...
>
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$ <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] "module load" compatibility

[Danny S. <Dan...@EM...>]

Hi Paul,

All right, I meant the base vs specific module file behaviour when using switch. And we use the base version only.

Okay, there are some drawbacks. But I think in our case we really want to load the default version.

Our use case a bit bizarre. 😉

Basically what we want is to ‘semi-recover’ from a situation where only PATH is messed up (without going into details).
So we just load the system default modules again to have at least a good enough environment.

Best regards,
Danny


From: Paul Markfort <pau...@gm...>
Sent: 21 April 2023 17:02
To: mod...@li...
Subject: Re: [Modules] "module load" compatibility

Mine was just an example (the module I was using to test is actually call base/dot - it adds ". " to the path, at the end. base is a folder, and dot is the name of a module file in that folder). If you are loading a specific module file, I don't
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltERtMYvfPKBF6NwOHrzUHitsg8S3HQplZLb3Wu_8_i_X8Bm1zPtR6DCtQe3SHjp2cRqqJKnT01toJiNJRMEB1O-FAS45QBdyfsA58$>   ‌
ZjQcmQRYFpfptBannerEnd

Mine was just an example (the module I was using to test is actually call base/dot - it adds "." to the path, at the end. base is a folder, and dot is the name of a module file in that folder).



If you are loading a specific module file, I don't foresee a problem.

If base is a folder with multiple modules under it, then this could end up unloading another module under base (if the default module isn't already loaded).





On 4/21/2023 9:47 AM, Danny Sternkopf wrote:

> Hi Paul,

>

> Thank you for the advices!

>

> As we’re just using the base module for loading I tested

> ‘module switch base base’

>

> and it seems to work (module gets reloaded incl dependencies even if loaded already). This is what we want.

>

> Do you see any problem with it in comparison to the dot version ‘ module switch base/dot base/dot’ you recommended?

> Any other drawbacks?

>

> Best regards,

> Danny

>

> From: Paul Markfort <pau...@gm...<mailto:pau...@gm...>>

> Sent: 21 April 2023 16:15

> To: mod...@li...<mailto:mod...@li...>

> Subject: Re: [Modules] "module load" compatibility

>

> I suggest (if you can) that you update to: Modules Release 5. 2. 0 (2022-11-08) (has the same issue, but has many improvements and corrections). Try using "module switch" instead of module load. Note, you can only load one module with module

> ZjQcmQRYFpfptBannerStart

> This Message Is From an External Sender

> This message came from outside your organization.

>      Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltPJtMZlpNr756NSmphjamxzF7ZB1hr2Q-JeXQq2fj5Akb0iruOBqzqpwYmNVNmR5ZwDpgVelvBz8Eyc5ZCLiWq-JqhWgnxMfSddmU$>   ‌

> ZjQcmQRYFpfptBannerEnd

>

> I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)

>

> (has the same issue, but has many improvements and corrections).

>

>

>

> Try using "module switch" instead of module load.

>

> Note, you can only load one module with module switch.

>

>

>

> There are some issues with this.

>

> If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.

>

>

>

> A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).

>

>

>

> As in:

>

>    module switch base/dot base/dot

>

>

>

> However, you should see the previous post about "module load" behavior.

>

>

>

>

>

> Notes:

>

>

>

> This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).

>

>

>

> I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).

>

>

>

>

>

>

>

> On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:

>

>> Dear all,

>

>>

>

>> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://urldefense.com/v3/__https://modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$>[modules[.]readthedocs[.]io]<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3chttps:/urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$%3e%5bmodules%5b.%5dreadthedocs%5b.%5dio%5d>says

>

>>

>

>> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.

>

>>

>

>> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.

>

>>

>

>> Thank you and best regards,

>

>>

>

>> Jens-Olaf

>

>> ---

>

>> Dr. Jens-Olaf Beismann          Benchmarking Expert

>

>> High Performance Computing      NEC Deutschland GmbH     https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$>[nec[.]com]<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>

><https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3chttps:/urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$%3e%5bnec%5b.%5dcom%5d%3e>

>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)

>

>> ---

>

>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf

>

>> Geschäftsführer: Yuichi Kojima

>

>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

>

>>

>

>>

>

>> _______________________________________________

>

>> Modules-interest mailing list

>

>> Mod...@li...<mailto:Mod...@li...<mailto:Mod...@li...%3cmailto:Mod...@li...>>

>

>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

><https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

>>

>

>

>

> --

>

> --------------------------------------------------------

>

> 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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$>[paulfm[.]com]<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>

><https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3chttps:/urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$%3e%5bpaulfm%5b.%5dcom%5d%3e>

> --------------------------------------------------------

>

>

>

>

>

> _______________________________________________

>

> Modules-interest mailing list

>

> Mod...@li...<mailto:Mod...@li...<mailto:Mod...@li...%3cmailto:Mod...@li...>>

>

> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

><https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3chttps:/urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$%3e%5blists%5b.%5dsourceforge%5b.%5dnet%5d%3e>

>

>

> _______________________________________________

> Modules-interest mailing list

> Mod...@li...<mailto:Mod...@li...>

> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]

>



--

--------------------------------------------------------

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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxu0sXzMu$>[paulfm[.]com]

--------------------------------------------------------





_______________________________________________

Modules-interest mailing list

Mod...@li...<mailto:Mod...@li...>

https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!n0ZuYQRLDWt3Uk0PHxsQk7aYyUYXpEfj0-EGP_2EH1cEv_klW6CPmEyqlkizHLNJgiHTEf3Yi5cO_4cBxuaQ5Wlr$>[lists[.]sourceforge[.]net]

Re: [Modules] "module load" compatibility

[Paul M. <pau...@gm...>]

Mine was just an example (the module I was using to test is actually call base/dot - it adds "." to the path, at the end. base is a folder, and dot is the name of a module file in that folder).

If you are loading a specific module file, I don't foresee a problem.
If base is a folder with multiple modules under it, then this could end up unloading another module under base (if the default module isn't already loaded).


On 4/21/2023 9:47 AM, Danny Sternkopf wrote:
> Hi Paul,
> 
> Thank you for the advices!
> 
> As we’re just using the base module for loading I tested
> ‘module switch base base’
> 
> and it seems to work (module gets reloaded incl dependencies even if loaded already). This is what we want.
> 
> Do you see any problem with it in comparison to the dot version ‘ module switch base/dot base/dot’ you recommended?
> Any other drawbacks?
> 
> Best regards,
> Danny
> 
> From: Paul Markfort <pau...@gm...>
> Sent: 21 April 2023 16:15
> To: mod...@li...
> Subject: Re: [Modules] "module load" compatibility
> 
> I suggest (if you can) that you update to: Modules Release 5. 2. 0 (2022-11-08) (has the same issue, but has many improvements and corrections). Try using "module switch" instead of module load. Note, you can only load one module with module
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>      Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltPJtMZlpNr756NSmphjamxzF7ZB1hr2Q-JeXQq2fj5Akb0iruOBqzqpwYmNVNmR5ZwDpgVelvBz8Eyc5ZCLiWq-JqhWgnxMfSddmU$>   ‌
> ZjQcmQRYFpfptBannerEnd
> 
> I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)
> 
> (has the same issue, but has many improvements and corrections).
> 
> 
> 
> Try using "module switch" instead of module load.
> 
> Note, you can only load one module with module switch.
> 
> 
> 
> There are some issues with this.
> 
> If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.
> 
> 
> 
> A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).
> 
> 
> 
> As in:
> 
>    module switch base/dot base/dot
> 
> 
> 
> However, you should see the previous post about "module load" behavior.
> 
> 
> 
> 
> 
> Notes:
> 
> 
> 
> This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).
> 
> 
> 
> I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).
> 
> 
> 
> 
> 
> 
> 
> On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:
> 
>> Dear all,
> 
>>
> 
>> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://urldefense.com/v3/__https://modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$>[modules[.]readthedocs[.]io] says
> 
>>
> 
>> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.
> 
>>
> 
>> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.
> 
>>
> 
>> Thank you and best regards,
> 
>>
> 
>> Jens-Olaf
> 
>> ---
> 
>> Dr. Jens-Olaf Beismann          Benchmarking Expert
> 
>> High Performance Computing      NEC Deutschland GmbH     https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$>[nec[.]com]
> 
>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> 
>> ---
> 
>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> 
>> Geschäftsführer: Yuichi Kojima
> 
>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> 
>>
> 
>>
> 
>> _______________________________________________
> 
>> Modules-interest mailing list
> 
>> Mod...@li...<mailto:Mod...@li...>
> 
>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]
> 
>>
> 
> 
> 
> --
> 
> --------------------------------------------------------
> 
> 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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$>[paulfm[.]com]
> 
> --------------------------------------------------------
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Modules-interest mailing list
> 
> Mod...@li...<mailto:Mod...@li...>
> 
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]
> 
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
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/
--------------------------------------------------------

Re: [Modules] "module load" compatibility

[Danny S. <Dan...@EM...>]

Hi Paul,

Thank you for the advices!

As we’re just using the base module for loading I tested
‘module switch base base’

and it seems to work (module gets reloaded incl dependencies even if loaded already). This is what we want.

Do you see any problem with it in comparison to the dot version ‘ module switch base/dot base/dot’ you recommended?
Any other drawbacks?

Best regards,
Danny

From: Paul Markfort <pau...@gm...>
Sent: 21 April 2023 16:15
To: mod...@li...
Subject: Re: [Modules] "module load" compatibility

I suggest (if you can) that you update to: Modules Release 5. 2. 0 (2022-11-08) (has the same issue, but has many improvements and corrections). Try using "module switch" instead of module load. Note, you can only load one module with module
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BQNorrFsuw!2ltPJtMZlpNr756NSmphjamxzF7ZB1hr2Q-JeXQq2fj5Akb0iruOBqzqpwYmNVNmR5ZwDpgVelvBz8Eyc5ZCLiWq-JqhWgnxMfSddmU$>   ‌
ZjQcmQRYFpfptBannerEnd

I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)

(has the same issue, but has many improvements and corrections).



Try using "module switch" instead of module load.

Note, you can only load one module with module switch.



There are some issues with this.

If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.



A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).



As in:

  module switch base/dot base/dot



However, you should see the previous post about "module load" behavior.





Notes:



This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).



I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).







On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:

> Dear all,

>

> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://urldefense.com/v3/__https://modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$<https://urldefense.com/v3/__https:/modules.readthedocs.io/en/latest/changes.html__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKIRttPUj$>[modules[.]readthedocs[.]io] says

>

> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.

>

> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.

>

> Thank you and best regards,

>

> Jens-Olaf

> ---

> Dr. Jens-Olaf Beismann          Benchmarking Expert

> High Performance Computing      NEC Deutschland GmbH     https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$<https://urldefense.com/v3/__https:/www.nec.com/en/global/solutions/hpc/__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKKfqIEBN$>[nec[.]com]

> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)

> ---

> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf

> Geschäftsführer: Yuichi Kojima

> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

>

>

> _______________________________________________

> Modules-interest mailing list

> Mod...@li...<mailto:Mod...@li...>

> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]

>



--

--------------------------------------------------------

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: https://urldefense.com/v3/__http://paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$<https://urldefense.com/v3/__http:/paulfm.com/*paulfm/__;fg!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKERnxvvu$>[paulfm[.]com]

--------------------------------------------------------





_______________________________________________

Modules-interest mailing list

Mod...@li...<mailto:Mod...@li...>

https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/modules-interest__;!!BQNorrFsuw!iyB3C-H01tIHSv2CgndWyb7U49AY6hVdSg5RDbM9FbXSl3nd0g3Zl38BGprZaJVR3AkUJZa4fEQi0nJiKL8jB-da$>[lists[.]sourceforge[.]net]

Re: [Modules] "module load" compatibility

[Paul M. <pau...@gm...>]

Xavier,

Do you think it might be helpful to add an option to module load to support reloading the module even if it is loaded (which would be implimented as a switch)?

Or to module switch so you not only don't have to specify the module twice - but can list several modules to be reloaded (unloaded, then loaded - AKA switched with themselves).  Having to specify the module twice increases the chance of typos and makes debugging harder.

Or perhaps an additional command (maybe a change to the module reload command so you can specify a sub-set of modules to reload, you might want to allow -f if a subset of modules is listed).



On 4/21/2023 9:14 AM, Paul Markfort wrote:
> I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)
> (has the same issue, but has many improvements and corrections).
> 
> Try using "module switch" instead of module load.
> Note, you can only load one module with module switch.
> 
> There are some issues with this.
> If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.
> 
> A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).
> 
> As in:
>   module switch base/dot base/dot
> 
> However, you should see the previous post about "module load" behavior.
> 
> 
> Notes:
> 
> This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).
> 
> I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).
> 
> 
> 
> On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:
>> Dear all,
>>
>> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://modules.readthedocs.io/en/latest/changes.html says
>>
>> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.
>>
>> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.
>>
>> Thank you and best regards,
>>
>> Jens-Olaf
>> ---
>> Dr. Jens-Olaf Beismann          Benchmarking Expert
>> High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
>> ---
>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
>> Geschäftsführer: Yuichi Kojima
>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> 

-- 
--------------------------------------------------------
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/
--------------------------------------------------------

Re: [Modules] "module load" compatibility

[Paul M. <pau...@gm...>]

I suggest (if you can) that you update to: Modules Release 5.2.0 (2022-11-08)
(has the same issue, but has many improvements and corrections).

Try using "module switch" instead of module load.
Note, you can only load one module with module switch.

There are some issues with this.
If the module you are loading is not loaded, and is the same base path as another loaded module, module switch will unload that other module.

A way around this is to specify the same module for modulefile1 and modulefile2 (rather than leave modulefile1 unspecified).

As in:
  module switch base/dot base/dot

However, you should see the previous post about "module load" behavior.


Notes:

This behavior change from the old 3.2.10 binary version to the TCL source version caused me some headaches when I first switched (some years ago).

I changed some of my shell initialization module loads to module source (supported with-out full module paths in 5.2.0), as I needed them to be processed every time the shell initialization script ran (advantage: sourced modules can't be unloaded).  For instance, when I want to load a module to define shell aliases (which aren't inherited by the shell).



On 4/21/2023 3:54 AM, Jens-Olaf Beismann wrote:
> Dear all,
> 
> it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://modules.readthedocs.io/en/latest/changes.html says
> 
> When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.
> 
> Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.
> 
> Thank you and best regards,
> 
> Jens-Olaf
> ---
> Dr. Jens-Olaf Beismann          Benchmarking Expert
> High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> ---
> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> Geschäftsführer: Yuichi Kojima
> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
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/
--------------------------------------------------------

[Modules] "module load" compatibility

[Jens-Olaf B. <Jen...@EM...>]

Dear all,

it appears that with module 3.2.10 a load of an already loaded module is executed again while it is not with version 4.5.2. https://modules.readthedocs.io/en/latest/changes.html says

When an already loaded modulefiles is asked for load again, compatibility version will refresh the shell alias definition this modulefile hold if any, whereas Modules 4 will ignore the new load order.

Is there a way to achieve the old behavior with version 4.5.2? Our tests with the -f option have not been successful in this respect, and as per the documentation we don't want to manipulate _LMFILES_ and LOADEDMODULES explicitly.

Thank you and best regards,

Jens-Olaf
---
Dr. Jens-Olaf Beismann          Benchmarking Expert
High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
---
NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
Geschäftsführer: Yuichi Kojima
Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

Re: [Modules] "module load" behavior in module 3.2.10/4.5.2

[Xavier D. <xav...@gm...>]

Paul's guess is correct.

On version 4.5.2, "module switch intel intel/2020" means:

- module unload intel
- conflict intel
- module load intel/2020
- prereq intel/2020

Whereas "module switch intel/2020" means:

- module unload intel
- module load intel/2020
- prereq intel/2020

As switched-off module shares the same root name than switched-on
module, it is a bug to declare switched-off module a conflict. It was
reported in issue #355 [1] and fixed in version 4.5.3 [2]

If your customer runs on EL8, I suggest to open an issue on RedHat's
bugzilla [3] for this and ask for a package update (to version 4.5.3).

Regards,
Xavier

[1] https://github.com/cea-hpc/modules/issues/355
[2] https://modules.readthedocs.io/en/stable/NEWS.html#modules-4-5-3-2020-08-31
[3] https://bugzilla.redhat.com/

Le jeu. 20 avr. 2023 à 16:24, Paul Markfort <pau...@gm...> a écrit :
>
> A "guess" is module switch also implies a definition of conflict/require
> When you don't specifically name the module being removed, it isn't defined as a conflict.
>
> I suspect if you use:
>         module switch intel/2020 intel/2020
> You will get a similar error.
>
> On 4/20/2023 7:18 AM, Jens-Olaf Beismann wrote:
> > Merci beaucoup, Xavier,
> >
> > that works! Just to clarify: the documentation says
> >
> > "switch [options] [modulefile1] modulefile2
> >     Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified,
> >     then it is assumed to be the currently loaded module with the same root
> >     name as modulefile2."
> >
> > My understanding is that
> >
> > module switch intel/2020
> >
> > should be equivalent to
> >
> > module switch intel intel/2020
> >
> > but with the latter I get
> >
> > Loading intel/2020
> >    ERROR: Conflicting 'jotest/1.0' is loading
> >
> > Loading jotest/1.0
> >    WARNING: Load of switched-on intel/2020 failed
> >    ERROR: Load of requirement 'intel/2020' failed
> >
> > Does that mean that "modulefile1" in the switch command also has to be a fully qualified modulefile name?
> >
> > Viele Grüße,
> >
> > Jens-Olaf
> > ---
> > Dr. Jens-Olaf Beismann          Benchmarking Expert
> > High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
> > Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> > ---
> > NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> > Geschäftsführer: Yuichi Kojima
> > Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> >
> >> -----Original Message-----
> >> From: Xav...@CE... <Xav...@CE...>
> >> Sent: 20 April 2023 11:46
> >> To: mod...@li...
> >> Subject: Re: [Modules] "module load" behavior in module 3.2.10/4.5.2
> >>
> >> Hello Jens-Olaf,
> >>
> >> Starting version 4.2, load and unload commands inside modulefile
> >> imply definition of requirement or conflict.
> >>
> >> "module unload intel" means unload intel + conflict intel
> >> "module load intel/2020" means load intel/2020 + prereq intel/2020
> >>
> >> Option --not-req allows to skip requirement/conflict definition. It
> >> is available starting version 4.7.0.
> >>
> >> With version 4.5.2, changing these two commands into:
> >>
> >> module switch intel/2020
> >>
> >> Should do what you expect.
> >>
> >> Regards,
> >> Xavier
> >>
> >>
> >> On Thu, 2023-04-20 at 07:33 +0000, Jens-Olaf Beismann wrote:
> >>> Good morning,
> >>>
> >>> one of our customers observed a different behavior of commands in a
> >>> module file when using it with either modules version 3.2.10 or
> >>> version 4.5.2.
> >>>
> >>> The module file (called jotest/1.0 for testing purposes) contains
> >>> these lines
> >>>
> >>> module unload intel
> >>> module load intel/2020
> >>>
> >>> Among the available modules we only have
> >>>
> >>> intel/2020(default)
> >>>
> >>> i.e. there is no other module file in the "intel" directory.
> >>>
> >>> Now "module load jotest" works fine with version 3.2.10, i.e.
> >>> afterwards intel/2020 and jotest/1.0 are loaded (independent of
> >>> intel/2020 being loaded before or not).
> >>>
> >>> With version 4.5.2, however, we get this error
> >>>
> >>> % module load jotest
> >>> Loading intel/2020
> >>>    ERROR: Conflicting 'jotest/1.0' is loading
> >>>
> >>> Loading jotest/1.0
> >>>    ERROR: Load of requirement 'intel/2020' failed
> >>>
> >>> We are still struggling to understand the actual reason for the
> >>> error issued for "module load intel/2020" and therefore didn't yet
> >>> find a way to achieve the desired result with 4.5.2. Any hints
> >>> would be highly appreciated, in particular we'd like to understand
> >>> if there's something conceptionally wrong with the unload/load
> >>> sequence in "jotest/1.0".
> >>>
> >>> Thank you and best regards,
> >>>
> >>> Jens-Olaf
> >>> ---
> >>> Dr. Jens-Olaf Beismann          Benchmarking Expert
> >>> High Performance Computing      NEC Deutschland GmbH
> >>>
> >> https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!
> >> !BQNorrFsuw!jqIK5XPEUH9M-
> >> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> >> nwk8LQLWGhsecJ4EKHg26uA$[nec[.]com]
> >>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> >>> ---
> >>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> >>> Geschäftsführer: Yuichi Kojima
> >>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> >>>
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>>
> >> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
> >> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
> >> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> >> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
> >> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
> >> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> >> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> --------------------------------------------------------
> 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/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest