modules-interest — Discussion forum for modules usage.

Re: [Modules] unloading dependent modules

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

Dear Danny,

Could you provide the whole modulefile, the command you run and loaded
module you get after running the commands. It would help to guide you.

When defining dependencies with "module load" or "prereq", it is
important not to enclose these commands within an evaluation mode test
(e.g., "if { [ module-info mode remove ] } {").

This way, what is done at load evaluation is reversed during unload.

Let's say you have "module load tbb" in your modulefile. tbb will get
loaded as a dependency when loading your module and it will be
automatically unloaded when unloading your module.

@Paul: I do not think there is a difference between using *-path
commands or "module use" in modulefile.

Best regards,
Xavier

Le ven. 6 oct. 2023 à 18:35, Paul Markfort <pau...@gm...> a écrit :
>
> Took me awhile to find it (module use, completely forgot what the command was, just remembered there was one), but you should use the "module use"  or "module use --append" command to mess with MODULEPATH.
>
> My guess is those modules you are having trouble with, are in the /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/ folder.
> (the module command can't find them to unload them).
>
> Hopefully, the implied "module unuse" command waits until the end of module processing to run (when the module unload is run, the module use becomes a module unuse).
>
> Xavier,
> May I suggest you update the man page so the append-path and prepend-path items suggest you use "module use" to modify MODULEPATH.
>
>
> On 10/6/2023 10:20 AM, Danny Sternkopf wrote:
> > Dear all,
> >
> > we have module which is loading quite few submodules. But when unloading it not all the dependent modules get unloaded. That's why we us a section like this:
> >
> > if { [ module-info mode remove ] } {
> >    module unload tbb
> >    module unload compiler-rt
> >    module unload oclfpga
> >    remove-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
> > }
> >
> > I also tried with a "module-info mode unload" section, but there is no difference.
> >
> > We're using:
> > $ module --version
> > Modules Release 4.5.2 (2020-07-30)
> >
> > Should it work like this? Or is there something completely wrong here?
> >
> > The "module-info mode load" section works as expected btw.
> > if { [ module-info mode load ] } {
> >    prepend-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
> > }
> >
> > Thank you and Best regards,
> > Danny

Re: [Modules] unloading dependent modules

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

Took me awhile to find it (module use, completely forgot what the command was, just remembered there was one), but you should use the "module use"  or "module use --append" command to mess with MODULEPATH.

My guess is those modules you are having trouble with, are in the /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/ folder.
(the module command can't find them to unload them).

Hopefully, the implied "module unuse" command waits until the end of module processing to run (when the module unload is run, the module use becomes a module unuse).

Xavier,
May I suggest you update the man page so the append-path and prepend-path items suggest you use "module use" to modify MODULEPATH.


On 10/6/2023 10:20 AM, Danny Sternkopf wrote:
> Dear all,
> 
> we have module which is loading quite few submodules. But when unloading it not all the dependent modules get unloaded. That's why we us a section like this:
> 
> if { [ module-info mode remove ] } {
>    module unload tbb
>    module unload compiler-rt
>    module unload oclfpga
>    remove-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
> }
> 
> I also tried with a "module-info mode unload" section, but there is no difference.
> 
> We're using:
> $ module --version
> Modules Release 4.5.2 (2020-07-30)
> 
> Should it work like this? Or is there something completely wrong here?
> 
> The "module-info mode load" section works as expected btw.
> if { [ module-info mode load ] } {
>    prepend-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
> }
> 
> Thank you and Best regards,
> Danny
> 
> Senior System Analyst, HPCE Division
> NEC Deutschland GmbH
> Frankfurter Strasse 135, 63067 Offenbach, Germany
> Mobile:  +49 (0)1522 2851510
> Office:  +49 (0)69 8062 3488
> 
> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14-16, D-40547 Düsseldorf, Germany
> Geschäftsführer: Christopher Richard Jackson  -  Handelsregister Düsseldorf HRB 579413
> 
> 
> 
> 
> _______________________________________________
> 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] unloading dependent modules

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

Dear all,

we have module which is loading quite few submodules. But when unloading it not all the dependent modules get unloaded. That's why we us a section like this:

if { [ module-info mode remove ] } {
  module unload tbb
  module unload compiler-rt
  module unload oclfpga
  remove-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
}

I also tried with a "module-info mode unload" section, but there is no difference.

We're using:
$ module --version
Modules Release 4.5.2 (2020-07-30)

Should it work like this? Or is there something completely wrong here?

The "module-info mode load" section works as expected btw.
if { [ module-info mode load ] } {
  prepend-path MODULEPATH /hpc/sw/modulefiles/nec/apps/intel_oneapi/.files_2023.2/
}

Thank you and Best regards,
Danny

Senior System Analyst, HPCE Division
NEC Deutschland GmbH
Frankfurter Strasse 135, 63067 Offenbach, Germany
Mobile:  +49 (0)1522 2851510
Office:  +49 (0)69 8062 3488

NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14-16, D-40547 Düsseldorf, Germany
Geschäftsführer: Christopher Richard Jackson  -  Handelsregister Düsseldorf HRB 579413

Re: [Modules] Switching the version of a sticky module?

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

Many thanks Adrien for your report. What you spot was actually a
specific bug of stickiness reloading detection with virtual modules.

Ticket #506 [1] was opened to work on this issue. It is now closed and
the fix will be part of version 5.4.

Regards,
Xavier

[1] https://github.com/cea-hpc/modules/issues/506

Le mar. 22 août 2023 à 09:23, Adrien COTTE - Groupe EOLEN
<adr...@eo...> a écrit :
>
> Yes, I already use sticky.
> And you are right, it's working on a simple module.
>
> So now, I need to debug to understand why I still have "Error: Unload of sticky module skipped".
>
> Maybe the usage of sticky is tricky on virtual modules?
>
> Thank you for your quick answer, it helps a lot.
>
> Best,
> Adrien
>
> ________________________________
> From: Xavier Delaruelle <xav...@gm...>
> Sent: Monday, August 21, 2023 7:13:58 PM
> To: Environment Modules usage and discussion. <mod...@li...>
> Subject: Re: [Modules] Switching the version of a sticky module?
>
> Hi Adrien,
>
> Such feature is already available since the introduction if the sticky tag.
>
> You just need to declare that the generic "pmix" name is sticky, not a
> precise version:
>
>   module-tag sticky pmix
>
> This way you are able to switch from one version to another without any error.
>
> See example at the end of the "Sticky modules" section in:
> https://modules.readthedocs.io/en/latest/MIGRATING.html#sticky-modules
>
> Best regards,
> Xavier
>
> Le lun. 21 août 2023 à 18:23, Adrien COTTE - Groupe EOLEN
> <adr...@eo...> a écrit :
> >
> > Hi,
> >
> > Many thanks again for the new "sticky_purge" config feature.
> >
> > But now, I would like to allow my users to switch the version of a sticky module.
> >
> > For example, my users must have a pmix module loaded, but no matters the version.
> >
> > $ module switch pmix/3.1.5 pmix/4.2.4
> >
> > Currently I have to use the "-f" option to perform that.
> >
> > Is it a good idea to add a "allow_sticky_switch_version" config or not?
> >
> > 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-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Question Module

[LAURENT F. <lau...@ev...>]

Ok Xavier.
Thanks a lot for your nice support (again 😉)
I will investigate more and probably find the solution with your inputs.
Bye
Laurent

From: Xavier Delaruelle <xav...@gm...>
Sent: 27 September 2023 14:09
To: LAURENT FIGADERE <lau...@at...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Question Module

Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.


Le mer. 27 sept. 2023 à 13:34, LAURENT FIGADERE <lau...@ev...<mailto:lau...@ev...>> a écrit :
Hi Xavier,

Ok thanks: I am adding the option set_shell_startup during the installation and cross check if it’s resolving my issue.

Concerning the header: you said ‘Modulefiles should start with the #%Module magic cookie string’
But as I told to you my modulefiles start with : ‘#%Module2.0’.
Does it mean I have to remove 2.0 ?

"2.0" can be kept. Version specification can be set right after #%Module".

I suspect that such error comes from .modulerc or .version files inside your modulepaths that do not start with "#%Module".

By running the command with --debug, you will be able to spot where this error comes from.

Regards,
Xavier


Regards
Laurent

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: 27 September 2023 13:23
To: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>; LAURENT FIGADERE <lau...@at...<mailto:lau...@at...>>
Subject: Re: [Modules] Question Module

Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Laurent,

Le mer. 27 sept. 2023 à 13:11, LAURENT FIGADERE via Modules-interest <mod...@li...<mailto:mod...@li...>> a écrit :
Hi all,

We are using for the moment module version 4.7.0.
With this version, I have sometimes this error:
Module ERROR: Magic cookie '#%Module' missing

Even the modulefiles exist and contains the header:
#%Module2.0

First question: do you know this issue root cause?

Modulefiles should start with the #%Module magic cookie string. This error is obtained when this magic cookie is not found at the start of the file.

You should be seing this error consistently for the same files. Running command in --debug mode would help to see the file with issues.

To give more info, we are loading the modulefiles in several jobs in parallel at the same time.

I saw in recent release, since 5.1, this documentation:
https://modules.readthedocs.io/en/latest/module.html#mconfig-mcookie_check

Can MODULES_MCOOKIE_CHECK or MODULES_MCOOKIE_VERSION_CHECK  help to resolve these errors?

MODULES_MCOOKIE_CHECK would help to disable the magic cookie check. But to use it you must ensure that only modulefiles are inside the modulepath directories.


And now, I have another question.
To try if it could help us to remove these errors, I tried to use module version 5.3.1.

But now, I am faced to another issue: even I source the bash init, I have this eror here after:
Like the init was not done properly.
Did somebody see this kind of issue?

Your test.sh script runs inside a sub-shell. It does not inherit the module shell function unless module was initialized in the upper shell session with the set_shell_startup option enabled (https://modules.readthedocs.io/en/latest/module.html#mconfig-set_shell_startup).

Regards,
Xavier

Re: [Modules] Question Module

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

Le mer. 27 sept. 2023 à 13:34, LAURENT FIGADERE <lau...@ev...>
a écrit :

> Hi Xavier,
>
>
>
> Ok thanks: I am adding the option set_shell_startup during the
> installation and cross check if it’s resolving my issue.
>
>
>
> Concerning the header: you said ‘Modulefiles should start with the
> #%Module magic cookie string’
>
> But as I told to you my modulefiles start with : ‘*#%Module2.0*’.
>
> Does it mean I have to remove *2.0* ?
>

"2.0" can be kept. Version specification can be set right after #%Module".

I suspect that such error comes from .modulerc or .version files inside
your modulepaths that do not start with "#%Module".

By running the command with --debug, you will be able to spot where this
error comes from.

Regards,
Xavier


>
>
> Regards
>
> Laurent
>
>
>
> *From:* Xavier Delaruelle <xav...@gm...>
> *Sent:* 27 September 2023 13:23
> *To:* Environment Modules usage and discussion. <
> mod...@li...>; LAURENT FIGADERE <
> lau...@at...>
> *Subject:* Re: [Modules] Question Module
>
>
>
> *Caution:* External email. Do not open attachments or click links, unless
> this email comes from a known sender and you know the content is safe.
>
>
>
> Hi Laurent,
>
>
>
> Le mer. 27 sept. 2023 à 13:11, LAURENT FIGADERE via Modules-interest <
> mod...@li...> a écrit :
>
> Hi all,
>
>
>
> We are using for the moment module version 4.7.0.
>
> With this version, I have sometimes this error:
>
> Module ERROR: Magic cookie '#%Module' missing
>
>
>
> Even the modulefiles exist and contains the header:
>
> #%Module2.0
>
>
>
> First question: do you know this issue root cause?
>
>
>
> Modulefiles should start with the #%Module magic cookie string. This error
> is obtained when this magic cookie is not found at the start of the file.
>
>
>
> You should be seing this error consistently for the same files. Running
> command in --debug mode would help to see the file with issues.
>
>
>
> To give more info, we are loading the modulefiles in several jobs in
> parallel at the same time.
>
>
>
> I saw in recent release, since *5.1,* this documentation:
>
> https://modules.readthedocs.io/en/latest/module.html#mconfig-mcookie_check
>
>
>
> Can MODULES_MCOOKIE_CHECK or MODULES_MCOOKIE_VERSION_CHECK  help to
> resolve these errors?
>
>
>
> MODULES_MCOOKIE_CHECK would help to disable the magic cookie check. But to
> use it you must ensure that only modulefiles are inside the modulepath
> directories.
>
>
>
>
>
> And now, I have another question.
>
> To try if it could help us to remove these errors, I tried to use module
> version 5.3.1.
>
>
>
> But now, I am faced to another issue: even I source the bash init, I have
> this eror here after:
>
> Like the init was not done properly.
>
> Did somebody see this kind of issue?
>
>
>
> Your test.sh script runs inside a sub-shell. It does not inherit the
> module shell function unless module was initialized in the upper shell
> session with the set_shell_startup option enabled (
> https://modules.readthedocs.io/en/latest/module.html#mconfig-set_shell_startup
> ).
>
>
>
> Regards,
>
> Xavier
>

Re: [Modules] Question Module

[LAURENT F. <lau...@ev...>]

Hi Xavier,

Ok thanks: I am adding the option set_shell_startup during the installation and cross check if it's resolving my issue.

Concerning the header: you said 'Modulefiles should start with the #%Module magic cookie string'
But as I told to you my modulefiles start with : '#%Module2.0'.
Does it mean I have to remove 2.0 ?

Regards
Laurent

From: Xavier Delaruelle <xav...@gm...>
Sent: 27 September 2023 13:23
To: Environment Modules usage and discussion. <mod...@li...>; LAURENT FIGADERE <lau...@at...>
Subject: Re: [Modules] Question Module

Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Laurent,

Le mer. 27 sept. 2023 à 13:11, LAURENT FIGADERE via Modules-interest <mod...@li...<mailto:mod...@li...>> a écrit :
Hi all,

We are using for the moment module version 4.7.0.
With this version, I have sometimes this error:
Module ERROR: Magic cookie '#%Module' missing

Even the modulefiles exist and contains the header:
#%Module2.0

First question: do you know this issue root cause?

Modulefiles should start with the #%Module magic cookie string. This error is obtained when this magic cookie is not found at the start of the file.

You should be seing this error consistently for the same files. Running command in --debug mode would help to see the file with issues.

To give more info, we are loading the modulefiles in several jobs in parallel at the same time.

I saw in recent release, since 5.1, this documentation:
https://modules.readthedocs.io/en/latest/module.html#mconfig-mcookie_check

Can MODULES_MCOOKIE_CHECK or MODULES_MCOOKIE_VERSION_CHECK  help to resolve these errors?

MODULES_MCOOKIE_CHECK would help to disable the magic cookie check. But to use it you must ensure that only modulefiles are inside the modulepath directories.


And now, I have another question.
To try if it could help us to remove these errors, I tried to use module version 5.3.1.

But now, I am faced to another issue: even I source the bash init, I have this eror here after:
[cid:image006.png@01D9F13B.AB5A8120]
Like the init was not done properly.
Did somebody see this kind of issue?

Your test.sh script runs inside a sub-shell. It does not inherit the module shell function unless module was initialized in the upper shell session with the set_shell_startup option enabled (https://modules.readthedocs.io/en/latest/module.html#mconfig-set_shell_startup).

Regards,
Xavier

Re: [Modules] Question Module

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

Hi Laurent,

Le mer. 27 sept. 2023 à 13:11, LAURENT FIGADERE via Modules-interest <
mod...@li...> a écrit :

> Hi all,
>
>
>
> We are using for the moment module version 4.7.0.
>
> With this version, I have sometimes this error:
>
> Module ERROR: Magic cookie '#%Module' missing
>
>
>
> Even the modulefiles exist and contains the header:
>
> #%Module2.0
>
>
>
> First question: do you know this issue root cause?
>

Modulefiles should start with the #%Module magic cookie string. This error
is obtained when this magic cookie is not found at the start of the file.

You should be seing this error consistently for the same files. Running
command in --debug mode would help to see the file with issues.


> To give more info, we are loading the modulefiles in several jobs in
> parallel at the same time.
>
>
>
> I saw in recent release, since *5.1,* this documentation:
>
> https://modules.readthedocs.io/en/latest/module.html#mconfig-mcookie_check
>
>
>
> Can MODULES_MCOOKIE_CHECK or MODULES_MCOOKIE_VERSION_CHECK  help to
> resolve these errors?
>

MODULES_MCOOKIE_CHECK would help to disable the magic cookie check. But to
use it you must ensure that only modulefiles are inside the modulepath
directories.


>
>
> And now, I have another question.
>
> To try if it could help us to remove these errors, I tried to use module
> version 5.3.1.
>
>
>
> But now, I am faced to another issue: even I source the bash init, I have
> this eror here after:
>
> Like the init was not done properly.
>
> Did somebody see this kind of issue?
>

Your test.sh script runs inside a sub-shell. It does not inherit the module
shell function unless module was initialized in the upper shell session
with the set_shell_startup option enabled (
https://modules.readthedocs.io/en/latest/module.html#mconfig-set_shell_startup
).

Regards,
Xavier

[Modules] Question Module

[LAURENT F. <lau...@ev...>]

Hi all,

We are using for the moment module version 4.7.0.

With this version, I have sometimes this error:
Module ERROR: Magic cookie '#%Module' missing

Even the modulefiles exist and contains the header:
#%Module2.0

First question: do you know this issue root cause?
To give more info, we are loading the modulefiles in several jobs in parallel at the same time.

I saw in recent release, since 5.1, this documentation:
https://modules.readthedocs.io/en/latest/module.html#mconfig-mcookie_check

Can MODULES_MCOOKIE_CHECK or MODULES_MCOOKIE_VERSION_CHECK  help to resolve these errors?

And now, I have another question.
To try if it could help us to remove these errors, I tried to use module version 5.3.1.

But now, I am faced to another issue: even I source the bash init, I have this eror here after:
[cid:image006.png@01D9F13B.AB5A8120]
Like the init was not done properly.
Did somebody see this kind of issue?


Kind regards,
Figadère Laurent
CAD Engineer - BDS RD Asic's
T: 01 86 53 72 26
39 avenue Jean Jaurès 78340 Les Clayes-sous-Bois - France
eviden.com<https://eviden.com/>
[LinkedIn icon]<https://www.linkedin.com/company/eviden> [Twitter icon] <https://twitter.com/EvidenLive>  [Instagram icon] <https://www.instagram.com/evidenlive>  [YouTube icon] <https://www.youtube.com/@EvidenLive>
[Eviden logo]

an atos business

Re: [Modules] Switching the version of a sticky module?

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

Yes, I already use sticky.
And you are right, it's working on a simple module.

So now, I need to debug to understand why I still have "Error: Unload of sticky module skipped".

Maybe the usage of sticky is tricky on virtual modules?

Thank you for your quick answer, it helps a lot.

Best,
Adrien

________________________________
From: Xavier Delaruelle <xav...@gm...>
Sent: Monday, August 21, 2023 7:13:58 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Switching the version of a sticky module?

Hi Adrien,

Such feature is already available since the introduction if the sticky tag.

You just need to declare that the generic "pmix" name is sticky, not a
precise version:

  module-tag sticky pmix

This way you are able to switch from one version to another without any error.

See example at the end of the "Sticky modules" section in:
https://modules.readthedocs.io/en/latest/MIGRATING.html#sticky-modules

Best regards,
Xavier

Le lun. 21 août 2023 à 18:23, Adrien COTTE - Groupe EOLEN
<adr...@eo...> a écrit :
>
> Hi,
>
> Many thanks again for the new "sticky_purge" config feature.
>
> But now, I would like to allow my users to switch the version of a sticky module.
>
> For example, my users must have a pmix module loaded, but no matters the version.
>
> $ module switch pmix/3.1.5 pmix/4.2.4
>
> Currently I have to use the "-f" option to perform that.
>
> Is it a good idea to add a "allow_sticky_switch_version" config or not?
>
> 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

Re: [Modules] Switching the version of a sticky module?

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

Hi Adrien,

Such feature is already available since the introduction if the sticky tag.

You just need to declare that the generic "pmix" name is sticky, not a
precise version:

  module-tag sticky pmix

This way you are able to switch from one version to another without any error.

See example at the end of the "Sticky modules" section in:
https://modules.readthedocs.io/en/latest/MIGRATING.html#sticky-modules

Best regards,
Xavier

Le lun. 21 août 2023 à 18:23, Adrien COTTE - Groupe EOLEN
<adr...@eo...> a écrit :
>
> Hi,
>
> Many thanks again for the new "sticky_purge" config feature.
>
> But now, I would like to allow my users to switch the version of a sticky module.
>
> For example, my users must have a pmix module loaded, but no matters the version.
>
> $ module switch pmix/3.1.5 pmix/4.2.4
>
> Currently I have to use the "-f" option to perform that.
>
> Is it a good idea to add a "allow_sticky_switch_version" config or not?
>
> Best,
> Adrien
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Switching the version of a sticky module?

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

Hi,

Many thanks again for the new "sticky_purge" config feature.

But now, I would like to allow my users to switch the version of a sticky module.

For example, my users must have a pmix module loaded, but no matters the version.

$ module switch pmix/3.1.5 pmix/4.2.4

Currently I have to use the "-f" option to perform that.

Is it a good idea to add a "allow_sticky_switch_version" config or not?

Best,
Adrien

[Modules] Purging sticky modules

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

Dear All,

A new configuration option named sticky_purge is introduced for next
version (5.4).

It defines the behavior of purge sub-command when unloading a sticky
or super-sticky module. By default an error is raised. sticky_purge
can be changed to emit a warning message instead or to be silent.

See example at https://modules.readthedocs.io/en/latest/MIGRATING.html#purging-sticky-modules

Regards,
Xavier

[Modules] Unique module name loaded

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

Dear All,

A new configuration option named unique_name_loaded is introduced for
next version (5.4).

When it is enabled, it allows only one module loaded per module name.
When loading a module that shares a name with an already loaded
module, an error is raised.

It is similar to the *One name rule* feature introduced by Lmod.

See example at https://modules.readthedocs.io/en/latest/MIGRATING.html#unique-module-name-loaded

Regards,
Xavier

[Modules] Specific modulepath labels

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

Dear All,

A new modulefile command named modulepath-label is introduced for next
version (5.4).

modulepath-label command defines a label to use to designate
modulepath in module avail output. This new command should be used in
global or modulepath-specific rc files.

See example at https://modules.readthedocs.io/en/latest/MIGRATING.html#specific-modulepath-labels

Regards,
Xavier

[Modules] Modules 5.3.1 released

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

Hello All,

Modules 5.3.1 is out. This release brings fixes for the few issue
spotted recently.

The changes introduced in this bugfix release are detailed at:

 https://modules.readthedocs.io/en/stable/NEWS.html#modules-5-3-1-2023-06-27

Details on the new features introduced in the 5.3 series are provided
in the MIGRATING document.

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

The tarball of this new version can be downloaded at:

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

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

 http://downloads.sourceforge.net/modules/modules-5.3.1-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

Special thanks to all the people who reported issues.

Best regards,
Xavier

Re: [Modules] source-sh without exporting functions

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

Hi Bhargav,

Currently the best option is to manually add unset-function commands
after the source-sh command.

I have created a feature request to add some option to source-sh to be
able to skip specific environment changes:
https://github.com/cea-hpc/modules/issues/503

Regards,
Xavier

Le mar. 27 juin 2023 à 03:30, Bhargav Katkam via Modules-interest
<mod...@li...> a écrit :
>
> 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
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

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
>