modules-interest — Discussion forum for modules usage.

[Modules] Roadmap for the next months

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

Dear All,

Shedding a bit more light on the project roadmap: next release (4.8)
should be out this summer, next step will be the work on 5.0 that is
expected for this autumn (to make it ready for EL9 inclusion).

Breaking changes of 5.0 will be:
- the new features of 4.x, like for instance the automated module
handling or the advanced version specifiers, will be set on by default
- requirement of Tcl>=8.5 (instead of >=8.4 currently)
- removal of the compatibility version (ability to ship Modules 3.2
along with Modules 4.x)

It is also a good time to report things that annoy you and should be
fixed or more generally things would you like to see changed. (please
open issue at https://github.com/cea-hpc/modules/issues or start a
discussion on this mailing-list)

Regards,
Xavier

[Modules] Ongoing work: module variants

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

Dear All,

It is time to unveil some details on the ongoing work: next version
(4.8) will be focused on the "variant" concept, aka the ability to
pass arguments to your modulefiles for their evaluation.

It will rely on the Spack syntax [1], already used on Modules advanced
version specifiers, as this syntax covers all needs and some of the
Modules user are already familiar with it.

For instance to load the MPI version of the HDF5 library built over
the foss21a toolchain, you will be able to write:

$ ml hdf5+mpi toolchain=foss21a

It will also be possible to define shortcut for variant, for instance
to abbreviate "toolchain=" by "%":

$ ml hdf5+mpi %foss21a

Regards,
Xavier

[1] https://spack.readthedocs.io/en/latest/basic_usage.html#variants

Re: [Modules] module use not working and unhiding modules

[Nick P. <nic...@gm...>]

First, I forgot to say thanks! So thanks! ;)

Thanks for the solution. :)

May I give a suggestion.
It would be nice if when paths are added they execute their modulerc, and
then enable a module-unhide command to tweak what users can
see without having too many if statements.

Probably my use case is limited, but it may be useful for transitioning
away from legacy naming schemes.

Thanks!


Den tir. 4. maj 2021 kl. 21.08 skrev Xavier Delaruelle <
xav...@gm...>:

> You can unhide hidden modules with the -a/--all command-line switch
> (unless if they are --hard hidden).
>
> You can also avoid hiding these modules in the RC file by using some
> conditional test, for instance:
>
> if {![is-loaded python/3.7.7]} {
>   module-hide matplotlib@:3.2.1
>   module-hide numpy@:1.18.2
>   module-hide scipy@:1.4.1
> }
>
> With such code, modules are not hidden when the python/3.7.7 module is
> loaded.
>
> You may also split the module-hide orders in the .modulerc files at
> the root of each modulepath directory. This way hiding rules are set
> closer to the modulefiles they target.
>
> Best regards,
> Xavier
>
> Le mar. 4 mai 2021 à 20:51, Nick Papior <nic...@gm...> a écrit :
> >
> > Well, that's embarrassing.
> >
> > Can one specify to unhide all modules in a folder? Should i then loop
> the modules in that path and unhide?
> >
> > Den tir. 4. maj 2021 kl. 20.45 skrev Xavier Delaruelle <
> xav...@gm...>:
> >>
> >> I correctly got the 3 files you sent.
> >>
> >> From what I can see, the "../env-modules/python-mods/3.7.7" directory
> >> is correctly enabled as modulepath entry.
> >>
> >> 3 modulefiles are found in it:
> >>   numpy/1.18.2
> >>   scipy/1.4.1
> >>   matplotlib/3.2.1
> >>
> >> But, the "../env-modules/modules/4.7.1/etc/rc" file defines these
> >> modules as hidden with the following commands:
> >>
> >>   module-hide matplotlib@:3.2.1
> >>   module-hide numpy@:1.18.2
> >>   module-hide scipy@:1.4.1
> >>
> >> As a result, there is no module to report in
> >> "../env-modules/python-mods/3.7.7" as all of them are hidden.
> >>
> >> So if you want to see/access these modules, the module-hide directives
> >> should be changed in the global RC file. By the way, ranges are
> >> inclusive so for instance "scipy@:1.4.1" matches all versions from
> >> 0.0.0 to 1.4.1 included.
> >>
> >> Best regards,
> >> Xavier
> >>
> >>
> >>
> >> Le mar. 4 mai 2021 à 20:20, Nick Papior <nic...@gm...> a écrit
> :
> >> >
> >> > FYI, I sent a response 4 hours ago with large attachments. I got a
> message saying it is on hold due to its size.
> >> > I don't know if I get a response on the decision on that? :)
> >> >
> >> > Den tir. 4. maj 2021 kl. 15.18 skrev Nick Papior <
> nic...@gm...>:
> >> >>
> >> >> Thanks!
> >> >>
> >> >> Here attached the 3 outputs.
> >> >>
> >> >> Please excuse me for having many more module-hide stuff in the rc
> file.
> >> >>
> >> >> If you want me to reduce the rc file I can, but I assume you search
> around the file for specific entries!
> >> >> In any case, let me know what you prefer!
> >> >>
> >> >> Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <
> Xav...@ce...>:
> >> >>>
> >> >>> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
> >> >>>
> >> >>> Hi list,
> >> >>>
> >> >>> I have always made use of the "module use <path>" extension to
> customize modules depending on other modules.
> >> >>> To do this I put "module use --append <path>" in a top level module.
> >> >>>
> >> >>> For example:
> >> >>>
> #%Module1.0#####################################################################
> >> >>> ##
> >> >>> ## python-3.7.7
> >> >>> ##
> >> >>>
> >> >>> set version 3.7.7
> >> >>> ...
> >> >>> module use --append /mypath/to/python/$version
> >> >>>
> >> >>> which then enables modules installed with python 3.7.7.
> >> >>> Now I want to use this in a combination with "module-hide" in
> >=4.6. And this is where things go wrong.
> >> >>>
> >> >>> I can get all versions to work if I don't use "module-hide", but as
> soon as I use an rc file in etc/rc that contains some hiding stuff, then
> using "module use ..." in a module does not work.
> >> >>> I can't even get it to work by doing "module use <path>" on the
> command line (i.e. outside of a module).
> >> >>>
> >> >>> The rc file contains something like this (plus additional stuff
> which *seems* irrelevant)
> >> >>> module-hide python@:2.7.17
> >> >>> module-hide python@3:3.7.6
> >> >>> module-hide python@3.8:3.8.3
> >> >>> module-hide python3@
> >> >>> module-hide numpy@:1.18.2
> >> >>>
> >> >>> My python/3.7.7 module contains the above "module use --append"
> statement.
> >> >>> But that seems to clash with the hiding, but I can't see why?
> >> >>>
> >> >>> Basically, if I don't have an rc file I get something like this
> (note the 2 sections)
> >> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> >> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1
> python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10
> python/3.7.6  python/3.8.0  python/3.8.2
> >> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4
> python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5
>  python/3.7.7  python/3.8.1  python/3.8.4
> >> >>>
> >> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/python/3.7.7
> -----------------------------------------------------------------------
> >> >>> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
> >> >>>
> >> >>> While if I have an rc file I get this (only 1 section)
> >> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> >> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1
> python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10
> python/3.7.6  python/3.8.0  python/3.8.2
> >> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4
> python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5
>  python/3.7.7  python/3.8.1  python/3.8.4
> >> >>>
> >> >>> I can't see why hiding modules should clash with module use...
> >> >>> Is there something I am missing?
> >> >>> I also tried renaming the python/$version folder to
> python-mods/$version, to no avail. Still only working without the rc file.
> >> >>>
> >> >>>
> >> >>> Hi Nick,
> >> >>>
> >> >>> Could you send me the result of the following commands (after doing
> a module purge) :
> >> >>>
> >> >>> $ module config --dump-state
> >> >>> $ module -DD load python/3.7.7
> >> >>> $ module -DD avail
> >> >>>
> >> >>> Please send me these outputs as a direct message if you do not want
> to expose these details on the mailing-list.
> >> >>>
> >> >>> Best regards,
> >> >>> Xavier
> >> >>>
> >> >>> _______________________________________________
> >> >>> Modules-interest mailing list
> >> >>> Mod...@li...
> >> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Kind regards Nick
> >> >
> >> >
> >> >
> >> > --
> >> > Kind regards Nick
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> > --
> > Kind regards Nick
> > _______________________________________________
> > 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
>


-- 
Kind regards Nick

Re: [Modules] module use not working and unhiding modules

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

You can unhide hidden modules with the -a/--all command-line switch
(unless if they are --hard hidden).

You can also avoid hiding these modules in the RC file by using some
conditional test, for instance:

if {![is-loaded python/3.7.7]} {
  module-hide matplotlib@:3.2.1
  module-hide numpy@:1.18.2
  module-hide scipy@:1.4.1
}

With such code, modules are not hidden when the python/3.7.7 module is loaded.

You may also split the module-hide orders in the .modulerc files at
the root of each modulepath directory. This way hiding rules are set
closer to the modulefiles they target.

Best regards,
Xavier

Le mar. 4 mai 2021 à 20:51, Nick Papior <nic...@gm...> a écrit :
>
> Well, that's embarrassing.
>
> Can one specify to unhide all modules in a folder? Should i then loop the modules in that path and unhide?
>
> Den tir. 4. maj 2021 kl. 20.45 skrev Xavier Delaruelle <xav...@gm...>:
>>
>> I correctly got the 3 files you sent.
>>
>> From what I can see, the "../env-modules/python-mods/3.7.7" directory
>> is correctly enabled as modulepath entry.
>>
>> 3 modulefiles are found in it:
>>   numpy/1.18.2
>>   scipy/1.4.1
>>   matplotlib/3.2.1
>>
>> But, the "../env-modules/modules/4.7.1/etc/rc" file defines these
>> modules as hidden with the following commands:
>>
>>   module-hide matplotlib@:3.2.1
>>   module-hide numpy@:1.18.2
>>   module-hide scipy@:1.4.1
>>
>> As a result, there is no module to report in
>> "../env-modules/python-mods/3.7.7" as all of them are hidden.
>>
>> So if you want to see/access these modules, the module-hide directives
>> should be changed in the global RC file. By the way, ranges are
>> inclusive so for instance "scipy@:1.4.1" matches all versions from
>> 0.0.0 to 1.4.1 included.
>>
>> Best regards,
>> Xavier
>>
>>
>>
>> Le mar. 4 mai 2021 à 20:20, Nick Papior <nic...@gm...> a écrit :
>> >
>> > FYI, I sent a response 4 hours ago with large attachments. I got a message saying it is on hold due to its size.
>> > I don't know if I get a response on the decision on that? :)
>> >
>> > Den tir. 4. maj 2021 kl. 15.18 skrev Nick Papior <nic...@gm...>:
>> >>
>> >> Thanks!
>> >>
>> >> Here attached the 3 outputs.
>> >>
>> >> Please excuse me for having many more module-hide stuff in the rc file.
>> >>
>> >> If you want me to reduce the rc file I can, but I assume you search around the file for specific entries!
>> >> In any case, let me know what you prefer!
>> >>
>> >> Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <Xav...@ce...>:
>> >>>
>> >>> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
>> >>>
>> >>> Hi list,
>> >>>
>> >>> I have always made use of the "module use <path>" extension to customize modules depending on other modules.
>> >>> To do this I put "module use --append <path>" in a top level module.
>> >>>
>> >>> For example:
>> >>> #%Module1.0#####################################################################
>> >>> ##
>> >>> ## python-3.7.7
>> >>> ##
>> >>>
>> >>> set version 3.7.7
>> >>> ...
>> >>> module use --append /mypath/to/python/$version
>> >>>
>> >>> which then enables modules installed with python 3.7.7.
>> >>> Now I want to use this in a combination with "module-hide" in >=4.6. And this is where things go wrong.
>> >>>
>> >>> I can get all versions to work if I don't use "module-hide", but as soon as I use an rc file in etc/rc that contains some hiding stuff, then using "module use ..." in a module does not work.
>> >>> I can't even get it to work by doing "module use <path>" on the command line (i.e. outside of a module).
>> >>>
>> >>> The rc file contains something like this (plus additional stuff which *seems* irrelevant)
>> >>> module-hide python@:2.7.17
>> >>> module-hide python@3:3.7.6
>> >>> module-hide python@3.8:3.8.3
>> >>> module-hide python3@
>> >>> module-hide numpy@:1.18.2
>> >>>
>> >>> My python/3.7.7 module contains the above "module use --append" statement.
>> >>> But that seems to clash with the hiding, but I can't see why?
>> >>>
>> >>> Basically, if I don't have an rc file I get something like this (note the 2 sections)
>> >>>  ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
>> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
>> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4
>> >>>
>> >>> ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/python/3.7.7 -----------------------------------------------------------------------
>> >>> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
>> >>>
>> >>> While if I have an rc file I get this (only 1 section)
>> >>>  ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
>> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
>> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4
>> >>>
>> >>> I can't see why hiding modules should clash with module use...
>> >>> Is there something I am missing?
>> >>> I also tried renaming the python/$version folder to python-mods/$version, to no avail. Still only working without the rc file.
>> >>>
>> >>>
>> >>> Hi Nick,
>> >>>
>> >>> Could you send me the result of the following commands (after doing a module purge) :
>> >>>
>> >>> $ module config --dump-state
>> >>> $ module -DD load python/3.7.7
>> >>> $ module -DD avail
>> >>>
>> >>> Please send me these outputs as a direct message if you do not want to expose these details on the mailing-list.
>> >>>
>> >>> Best regards,
>> >>> Xavier
>> >>>
>> >>> _______________________________________________
>> >>> Modules-interest mailing list
>> >>> Mod...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>> >>
>> >>
>> >>
>> >> --
>> >> Kind regards Nick
>> >
>> >
>> >
>> > --
>> > Kind regards Nick
>> > _______________________________________________
>> > 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
>
>
>
> --
> Kind regards Nick
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] module use not working and unhiding modules

[Nick P. <nic...@gm...>]

Well, that's embarrassing.

Can one specify to unhide all modules in a folder? Should i then loop the
modules in that path and unhide?

Den tir. 4. maj 2021 kl. 20.45 skrev Xavier Delaruelle <
xav...@gm...>:

> I correctly got the 3 files you sent.
>
> From what I can see, the "../env-modules/python-mods/3.7.7" directory
> is correctly enabled as modulepath entry.
>
> 3 modulefiles are found in it:
>   numpy/1.18.2
>   scipy/1.4.1
>   matplotlib/3.2.1
>
> But, the "../env-modules/modules/4.7.1/etc/rc" file defines these
> modules as hidden with the following commands:
>
>   module-hide matplotlib@:3.2.1
>   module-hide numpy@:1.18.2
>   module-hide scipy@:1.4.1
>
> As a result, there is no module to report in
> "../env-modules/python-mods/3.7.7" as all of them are hidden.
>
> So if you want to see/access these modules, the module-hide directives
> should be changed in the global RC file. By the way, ranges are
> inclusive so for instance "scipy@:1.4.1" matches all versions from
> 0.0.0 to 1.4.1 included.
>
> Best regards,
> Xavier
>
>
>
> Le mar. 4 mai 2021 à 20:20, Nick Papior <nic...@gm...> a écrit :
> >
> > FYI, I sent a response 4 hours ago with large attachments. I got a
> message saying it is on hold due to its size.
> > I don't know if I get a response on the decision on that? :)
> >
> > Den tir. 4. maj 2021 kl. 15.18 skrev Nick Papior <nic...@gm...>:
> >>
> >> Thanks!
> >>
> >> Here attached the 3 outputs.
> >>
> >> Please excuse me for having many more module-hide stuff in the rc file.
> >>
> >> If you want me to reduce the rc file I can, but I assume you search
> around the file for specific entries!
> >> In any case, let me know what you prefer!
> >>
> >> Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <
> Xav...@ce...>:
> >>>
> >>> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
> >>>
> >>> Hi list,
> >>>
> >>> I have always made use of the "module use <path>" extension to
> customize modules depending on other modules.
> >>> To do this I put "module use --append <path>" in a top level module.
> >>>
> >>> For example:
> >>>
> #%Module1.0#####################################################################
> >>> ##
> >>> ## python-3.7.7
> >>> ##
> >>>
> >>> set version 3.7.7
> >>> ...
> >>> module use --append /mypath/to/python/$version
> >>>
> >>> which then enables modules installed with python 3.7.7.
> >>> Now I want to use this in a combination with "module-hide" in >=4.6.
> And this is where things go wrong.
> >>>
> >>> I can get all versions to work if I don't use "module-hide", but as
> soon as I use an rc file in etc/rc that contains some hiding stuff, then
> using "module use ..." in a module does not work.
> >>> I can't even get it to work by doing "module use <path>" on the
> command line (i.e. outside of a module).
> >>>
> >>> The rc file contains something like this (plus additional stuff which
> *seems* irrelevant)
> >>> module-hide python@:2.7.17
> >>> module-hide python@3:3.7.6
> >>> module-hide python@3.8:3.8.3
> >>> module-hide python3@
> >>> module-hide numpy@:1.18.2
> >>>
> >>> My python/3.7.7 module contains the above "module use --append"
> statement.
> >>> But that seems to clash with the hiding, but I can't see why?
> >>>
> >>> Basically, if I don't have an rc file I get something like this (note
> the 2 sections)
> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
> python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
> python/3.8.0  python/3.8.2
> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
> python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
> python/3.8.1  python/3.8.4
> >>>
> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/python/3.7.7
> -----------------------------------------------------------------------
> >>> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
> >>>
> >>> While if I have an rc file I get this (only 1 section)
> >>>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> >>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
> python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
> python/3.8.0  python/3.8.2
> >>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
> python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
> python/3.8.1  python/3.8.4
> >>>
> >>> I can't see why hiding modules should clash with module use...
> >>> Is there something I am missing?
> >>> I also tried renaming the python/$version folder to
> python-mods/$version, to no avail. Still only working without the rc file.
> >>>
> >>>
> >>> Hi Nick,
> >>>
> >>> Could you send me the result of the following commands (after doing a
> module purge) :
> >>>
> >>> $ module config --dump-state
> >>> $ module -DD load python/3.7.7
> >>> $ module -DD avail
> >>>
> >>> Please send me these outputs as a direct message if you do not want to
> expose these details on the mailing-list.
> >>>
> >>> Best regards,
> >>> Xavier
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >>
> >>
> >> --
> >> Kind regards Nick
> >
> >
> >
> > --
> > Kind regards Nick
> > _______________________________________________
> > 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
>


-- 
Kind regards Nick

Re: [Modules] module use not working and unhiding modules

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

I correctly got the 3 files you sent.

>From what I can see, the "../env-modules/python-mods/3.7.7" directory
is correctly enabled as modulepath entry.

3 modulefiles are found in it:
  numpy/1.18.2
  scipy/1.4.1
  matplotlib/3.2.1

But, the "../env-modules/modules/4.7.1/etc/rc" file defines these
modules as hidden with the following commands:

  module-hide matplotlib@:3.2.1
  module-hide numpy@:1.18.2
  module-hide scipy@:1.4.1

As a result, there is no module to report in
"../env-modules/python-mods/3.7.7" as all of them are hidden.

So if you want to see/access these modules, the module-hide directives
should be changed in the global RC file. By the way, ranges are
inclusive so for instance "scipy@:1.4.1" matches all versions from
0.0.0 to 1.4.1 included.

Best regards,
Xavier



Le mar. 4 mai 2021 à 20:20, Nick Papior <nic...@gm...> a écrit :
>
> FYI, I sent a response 4 hours ago with large attachments. I got a message saying it is on hold due to its size.
> I don't know if I get a response on the decision on that? :)
>
> Den tir. 4. maj 2021 kl. 15.18 skrev Nick Papior <nic...@gm...>:
>>
>> Thanks!
>>
>> Here attached the 3 outputs.
>>
>> Please excuse me for having many more module-hide stuff in the rc file.
>>
>> If you want me to reduce the rc file I can, but I assume you search around the file for specific entries!
>> In any case, let me know what you prefer!
>>
>> Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <Xav...@ce...>:
>>>
>>> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
>>>
>>> Hi list,
>>>
>>> I have always made use of the "module use <path>" extension to customize modules depending on other modules.
>>> To do this I put "module use --append <path>" in a top level module.
>>>
>>> For example:
>>> #%Module1.0#####################################################################
>>> ##
>>> ## python-3.7.7
>>> ##
>>>
>>> set version 3.7.7
>>> ...
>>> module use --append /mypath/to/python/$version
>>>
>>> which then enables modules installed with python 3.7.7.
>>> Now I want to use this in a combination with "module-hide" in >=4.6. And this is where things go wrong.
>>>
>>> I can get all versions to work if I don't use "module-hide", but as soon as I use an rc file in etc/rc that contains some hiding stuff, then using "module use ..." in a module does not work.
>>> I can't even get it to work by doing "module use <path>" on the command line (i.e. outside of a module).
>>>
>>> The rc file contains something like this (plus additional stuff which *seems* irrelevant)
>>> module-hide python@:2.7.17
>>> module-hide python@3:3.7.6
>>> module-hide python@3.8:3.8.3
>>> module-hide python3@
>>> module-hide numpy@:1.18.2
>>>
>>> My python/3.7.7 module contains the above "module use --append" statement.
>>> But that seems to clash with the hiding, but I can't see why?
>>>
>>> Basically, if I don't have an rc file I get something like this (note the 2 sections)
>>>  ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
>>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
>>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4
>>>
>>> ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/python/3.7.7 -----------------------------------------------------------------------
>>> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
>>>
>>> While if I have an rc file I get this (only 1 section)
>>>  ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
>>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
>>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4
>>>
>>> I can't see why hiding modules should clash with module use...
>>> Is there something I am missing?
>>> I also tried renaming the python/$version folder to python-mods/$version, to no avail. Still only working without the rc file.
>>>
>>>
>>> Hi Nick,
>>>
>>> Could you send me the result of the following commands (after doing a module purge) :
>>>
>>> $ module config --dump-state
>>> $ module -DD load python/3.7.7
>>> $ module -DD avail
>>>
>>> Please send me these outputs as a direct message if you do not want to expose these details on the mailing-list.
>>>
>>> Best regards,
>>> Xavier
>>>
>>> _______________________________________________
>>> Modules-interest mailing list
>>> Mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
>>
>> --
>> Kind regards Nick
>
>
>
> --
> Kind regards Nick
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] module use not working and unhiding modules

[Nick P. <nic...@gm...>]

FYI, I sent a response 4 hours ago with large attachments. I got a message
saying it is on hold due to its size.
I don't know if I get a response on the decision on that? :)

Den tir. 4. maj 2021 kl. 15.18 skrev Nick Papior <nic...@gm...>:

> Thanks!
>
> Here attached the 3 outputs.
>
> Please excuse me for having many more module-hide stuff in the rc file.
>
> If you want me to reduce the rc file I can, but I assume you search around
> the file for specific entries!
> In any case, let me know what you prefer!
>
> Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <
> Xav...@ce...>:
>
>> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
>>
>> Hi list,
>>
>> I have always made use of the "module use <path>" extension to customize
>> modules depending on other modules.
>> To do this I put "module use --append <path>" in a top level module.
>>
>> For example:
>>
>> #%Module1.0#####################################################################
>> ##
>> ## python-3.7.7
>> ##
>>
>> set version 3.7.7
>> ...
>> module use --append /mypath/to/python/$version
>>
>> which then enables modules installed with python 3.7.7.
>> Now I want to use this in a combination with "module-hide" in >=4.6. And
>> this is where things go wrong.
>>
>> I can get all versions to work if I don't use "module-hide", but as soon
>> as I use an rc file in etc/rc that contains some hiding stuff, then using
>> "module use ..." in a module does not work.
>> I can't even get it to work by doing "module use <path>" on the command
>> line (i.e. outside of a module).
>>
>> The rc file contains something like this (plus additional stuff which
>> *seems* irrelevant)
>> module-hide python@:2.7.17
>> module-hide python@3:3.7.6
>> module-hide python@3.8:3.8.3
>> module-hide python3@
>> module-hide numpy@:1.18.2
>>
>> My python/3.7.7 module contains the above "module use --append" statement.
>> But that seems to clash with the hiding, but I can't see why?
>>
>> Basically, if I don't have an rc file I get something like this (note the
>> 2 sections)
>>  -----------------------------------------------------------------------
>> /zhome/0e/2/36189/dcc/env-modules/module-repo
>> ------------------------------------------------------------------------
>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
>>  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
>>  python/3.8.0  python/3.8.2
>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
>>  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
>>  python/3.8.1  python/3.8.4
>>
>> -----------------------------------------------------------------------
>> /zhome/0e/2/36189/dcc/env-modules/python/3.7.7
>> -----------------------------------------------------------------------
>> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
>>
>> While if I have an rc file I get this (only 1 section)
>>  -----------------------------------------------------------------------
>> /zhome/0e/2/36189/dcc/env-modules/module-repo
>> ------------------------------------------------------------------------
>> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
>>  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
>>  python/3.8.0  python/3.8.2
>> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
>>  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
>>  python/3.8.1  python/3.8.4
>>
>> I can't see why hiding modules should clash with module use...
>> Is there something I am missing?
>> I also tried renaming the python/$version folder to python-mods/$version,
>> to no avail. Still only working without the rc file.
>>
>>
>> Hi Nick,
>>
>> Could you send me the result of the following commands (after doing a
>> module purge) :
>>
>> $ module config --dump-state
>> $ module -DD load python/3.7.7
>> $ module -DD avail
>>
>> Please send me these outputs as a direct message if you do not want to
>> expose these details on the mailing-list.
>>
>> Best regards,
>> Xavier
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>
>
> --
> Kind regards Nick
>


-- 
Kind regards Nick

Re: [Modules] module use not working and unhiding modules

[Nick P. <nic...@gm...>]

Thanks!

Here attached the 3 outputs.

Please excuse me for having many more module-hide stuff in the rc file.

If you want me to reduce the rc file I can, but I assume you search around
the file for specific entries!
In any case, let me know what you prefer!

Den tir. 4. maj 2021 kl. 14.36 skrev Xav...@CE... <
Xav...@ce...>:

> Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
>
> Hi list,
>
> I have always made use of the "module use <path>" extension to customize
> modules depending on other modules.
> To do this I put "module use --append <path>" in a top level module.
>
> For example:
>
> #%Module1.0#####################################################################
> ##
> ## python-3.7.7
> ##
>
> set version 3.7.7
> ...
> module use --append /mypath/to/python/$version
>
> which then enables modules installed with python 3.7.7.
> Now I want to use this in a combination with "module-hide" in >=4.6. And
> this is where things go wrong.
>
> I can get all versions to work if I don't use "module-hide", but as soon
> as I use an rc file in etc/rc that contains some hiding stuff, then using
> "module use ..." in a module does not work.
> I can't even get it to work by doing "module use <path>" on the command
> line (i.e. outside of a module).
>
> The rc file contains something like this (plus additional stuff which
> *seems* irrelevant)
> module-hide python@:2.7.17
> module-hide python@3:3.7.6
> module-hide python@3.8:3.8.3
> module-hide python3@
> module-hide numpy@:1.18.2
>
> My python/3.7.7 module contains the above "module use --append" statement.
> But that seems to clash with the hiding, but I can't see why?
>
> Basically, if I don't have an rc file I get something like this (note the
> 2 sections)
>  -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
>  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
>  python/3.8.0  python/3.8.2
> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
>  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
>  python/3.8.1  python/3.8.4
>
> -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/python/3.7.7
> -----------------------------------------------------------------------
> matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1
>
> While if I have an rc file I get this (only 1 section)
>  -----------------------------------------------------------------------
> /zhome/0e/2/36189/dcc/env-modules/module-repo
> ------------------------------------------------------------------------
> modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
>  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
>  python/3.8.0  python/3.8.2
> modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
>  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
>  python/3.8.1  python/3.8.4
>
> I can't see why hiding modules should clash with module use...
> Is there something I am missing?
> I also tried renaming the python/$version folder to python-mods/$version,
> to no avail. Still only working without the rc file.
>
>
> Hi Nick,
>
> Could you send me the result of the following commands (after doing a
> module purge) :
>
> $ module config --dump-state
> $ module -DD load python/3.7.7
> $ module -DD avail
>
> Please send me these outputs as a direct message if you do not want to
> expose these details on the mailing-list.
>
> Best regards,
> Xavier
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>


-- 
Kind regards Nick

Re: [Modules] module use not working and unhiding modules

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

Le mardi 04 mai 2021 à 11:27 +0200, Nick Papior a écrit :
Hi list,

I have always made use of the "module use <path>" extension to customize modules depending on other modules.
To do this I put "module use --append <path>" in a top level module.

For example:
#%Module1.0#####################################################################
##
## python-3.7.7
##

set version 3.7.7
...
module use --append /mypath/to/python/$version

which then enables modules installed with python 3.7.7.
Now I want to use this in a combination with "module-hide" in >=4.6. And this is where things go wrong.

I can get all versions to work if I don't use "module-hide", but as soon as I use an rc file in etc/rc that contains some hiding stuff, then using "module use ..." in a module does not work.
I can't even get it to work by doing "module use <path>" on the command line (i.e. outside of a module).

The rc file contains something like this (plus additional stuff which *seems* irrelevant)
module-hide python@:2.7.17
module-hide python@3:3.7.6
module-hide python@3.8:3.8.3
module-hide python3@
module-hide numpy@:1.18.2

My python/3.7.7 module contains the above "module use --append" statement.
But that seems to clash with the hiding, but I can't see why?

Basically, if I don't have an rc file I get something like this (note the 2 sections)
 ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4

----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/python/3.7.7 -----------------------------------------------------------------------
matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1

While if I have an rc file I get this (only 1 section)
 ----------------------------------------------------------------------- /zhome/0e/2/36189/dcc/env-modules/module-repo ------------------------------------------------------------------------
modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5  python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6  python/3.8.0  python/3.8.2
modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0  python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7  python/3.8.1  python/3.8.4

I can't see why hiding modules should clash with module use...
Is there something I am missing?
I also tried renaming the python/$version folder to python-mods/$version, to no avail. Still only working without the rc file.

Hi Nick,

Could you send me the result of the following commands (after doing a module purge) :

$ module config --dump-state
$ module -DD load python/3.7.7
$ module -DD avail

Please send me these outputs as a direct message if you do not want to expose these details on the mailing-list.

Best regards,
Xavier

[Modules] module use not working and unhiding modules

[Nick P. <nic...@gm...>]

Hi list,

I have always made use of the "module use <path>" extension to customize
modules depending on other modules.
To do this I put "module use --append <path>" in a top level module.

For example:
#%Module1.0#####################################################################
##
## python-3.7.7
##

set version 3.7.7
...
module use --append /mypath/to/python/$version

which then enables modules installed with python 3.7.7.
Now I want to use this in a combination with "module-hide" in >=4.6. And
this is where things go wrong.

I can get all versions to work if I don't use "module-hide", but as soon as
I use an rc file in etc/rc that contains some hiding stuff, then using
"module use ..." in a module does not work.
I can't even get it to work by doing "module use <path>" on the command
line (i.e. outside of a module).

The rc file contains something like this (plus additional stuff which
*seems* irrelevant)
module-hide python@:2.7.17
module-hide python@3:3.7.6
module-hide python@3.8:3.8.3
module-hide python3@
module-hide numpy@:1.18.2

My python/3.7.7 module contains the above "module use --append" statement.
But that seems to clash with the hiding, but I can't see why?

Basically, if I don't have an rc file I get something like this (note the 2
sections)
 -----------------------------------------------------------------------
/zhome/0e/2/36189/dcc/env-modules/module-repo
------------------------------------------------------------------------
modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
 python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
 python/3.8.0  python/3.8.2
modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
 python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
 python/3.8.1  python/3.8.4

-----------------------------------------------------------------------
/zhome/0e/2/36189/dcc/env-modules/python/3.7.7
-----------------------------------------------------------------------
matplotlib/3.2.1  numpy/1.18.2  scipy/1.4.1

While if I have an rc file I get this (only 1 section)
 -----------------------------------------------------------------------
/zhome/0e/2/36189/dcc/env-modules/module-repo
------------------------------------------------------------------------
modules/4.3.1  modules/4.5.3  modules/4.7.1            python/3.2.5
 python/3.4.1  python/3.5.4  python/3.6.2  python/3.6.10  python/3.7.6
 python/3.8.0  python/3.8.2
modules/4.4.1  modules/4.6.1  python.scientific/3.8.4  python/3.3.0
 python/3.5.1  python/3.6.0  python/3.6.7  python/3.7.5   python/3.7.7
 python/3.8.1  python/3.8.4

I can't see why hiding modules should clash with module use...
Is there something I am missing?
I also tried renaming the python/$version folder to python-mods/$version,
to no avail. Still only working without the rc file.

-- 
Kind regards Nick

[Modules] Modules 4.7.1 released

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

Hello All,

Modules 4.7.1 is out. This release brings some fixes on the
documentation and clarifies the licence used by the project (GPLv2+).

The changes introduced in this bugfix release are detailed at:

 https://modules.readthedocs.io/en/stable/NEWS.html#modules-4-7-1-2021-04-06

Details on the new features introduced in the 4.7 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-4.7.1.tar.gz

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

 http://downloads.sourceforge.net/modules/modules-4.7.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] No 'module' binary after update

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

Vishnu,

Check that your shell init and dotfiles have the current modules installation and no remnant of a prior one:

grep -rl '\<module' {/etc/,~/.}*{sh*rc,profile*,login}

You could also try a traced shell initialization, best from a clean environment:

\env - \bash -lxc :  2>&1  |  grep -Ew '\.|source|unalias|[Mm]odule\w+'

You *should* see that files from /etc/profile.d/  really are being sourced, and you *should not* see a line like "unalias module".


With best regards,
Michael


On Mar 19, 2021, at 06:38, Vishnu V. Krishnan <vis...@gm...> wrote:
After this upgrade, if you start a new shell session, what is the
result of the `module -V` command typed in this shell?
$ module -V
bash: module: command not found
If in a shell session you `source /etc/profile.d/env-modules.sh` then
type `module -V`, what is the output obtained from both commands?
$ module -V
Modules Release 4.7.0 (2021-02-19)
So the issue is that it isn't being sourced. I don't see why though.

Re: [Modules] No 'module' binary after update

[Vishnu V. K. <vis...@gm...>]

> After this upgrade, if you start a new shell session, what is the
> result of the `module -V` command typed in this shell?
> 

$ module -V
bash: module: command not found

> If in a shell session you `source /etc/profile.d/env-modules.sh` then
> type `module -V`, what is the output obtained from both commands?
> 

$ module -V
Modules Release 4.7.0 (2021-02-19)


So the issue is that it isn't being sourced. I don't see why though.

Re: [Modules] No 'module' binary after update

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

Hi Vishnu,

After this upgrade, if you start a new shell session, what is the
result of the `module -V` command typed in this shell?

If in a shell session you `source /etc/profile.d/env-modules.sh` then
type `module -V`, what is the output obtained from both commands?

Regards,
Xavier

Le ven. 19 mars 2021 à 11:03, Vishnu V. Krishnan <vis...@gm...> a écrit :
>
> Hi Xavier,
>
> The build-script is as follows:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=env-modules
>
> and as you can see, it does create a symlink to the shell profile script in '/
> etc/profile.d/' (line 73). This was working before, and stopped after the
> update. So I'm confused as to what's changed.
>
> Vishnu
>
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] No 'module' binary after update

[Vishnu V. K. <vis...@gm...>]

Hi Xavier,

The build-script is as follows:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=env-modules

and as you can see, it does create a symlink to the shell profile script in '/
etc/profile.d/' (line 73). This was working before, and stopped after the 
update. So I'm confused as to what's changed.

Vishnu

Re: [Modules] No 'module' binary after update

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

Hi Vishnu,

`module` is not a binary but a shell function.

Maybe you just need to source the shell profile script in your
current shell session.

I do not know how environment module is packaged on AUR. Maybe
someone else on the mailing-list is more familiar with this
distribution ?

Regards,
Xavier


On Thu, 2021-03-18 at 12:04 +0530, Vishnu V. Krishnan wrote:
> Hi,
> 
> I've been using 'env-modules' on Archlinux for a while now,
> installed via the
> AUR (Arch User Repository) build-script:
> https://aur.archlinux.org/packages/env-modules/
> 
> After updating to the latest (4.7.0) version, I can no longer find
> the
> relevant binary. It does not exist at `/usr/bin/module`.
> 
> Am I missing some configuration I was supposed to perform?

[Modules] No 'module' binary after update

[Vishnu V. K. <vis...@gm...>]

Hi,

I've been using 'env-modules' on Archlinux for a while now, installed via the
AUR (Arch User Repository) build-script:
https://aur.archlinux.org/packages/env-modules/

After updating to the latest (4.7.0) version, I can no longer find the
relevant binary. It does not exist at `/usr/bin/module`.

Am I missing some configuration I was supposed to perform?
-- 
Vishnu

Re: [Modules] Get default version of module

[Bloecker, M. <Mar...@am...>]

One strategy that we have been using to achieve something similar is to use soft-links for each version-specific module. These version-specific modules all link to one "main" module file that implements the module logic. In this "main" module "module-info specified" can be used e.g. to map installation directories and similar. When the "main" module filename starts with a dot (i.e. '.main.module') it will also not show up during "module avail". 

Best Regards,

Martin

-----Original Message-----
From: Sternberg, Michael G. via Modules-interest <mod...@li...> 
Sent: Freitag, 26. Februar 2021 05:40
To: Environment Modules usage and discussion. <mod...@li...>
Cc: Sternberg, Michael G. <ste...@an...>
Subject: Re: [Modules] Get default version of module

[---EXTERNAL---]


The "module show foo" command could help to inspect the modulefile version and the full path that would be resolved for some module specification. Also, since you're sourcing, see the Modules-provided Tcl command "module-info specified" (literal) for the name requested on the command line.

But what are you trying to do?


I figure your generator script scans your application INSTALL_DIR and in effect represents it in the form of virtual modulefiles. If your motivation is to reduce code length or duplication, you could instead represent each application version by an actual modulefile containing a few appropriate Tcl "set" commands, then source a "main" modulefile for handling. Working with explicitly set variables should help to keep the tree and code simple and maintainable.


With best regards,
Michael


> On Feb 25, 2021, at 20:34, John Peter Yamauchi (jyamauchi) <jya...@mi...> wrote:
> Hi all,
> I’ve developed a system for my environment that auto-generates virtual modulefiles based on versions of tools that are installed.  The modules all point to a single modulefile that parses out the tool and version name from the name of the virtual module to set environment variables.
>
> Loading these modules works without a hitch.  However, sourcing them causes issues, since I have to pass in the path to the generic module.  I am passing in the tool name, but I need to get the version name.
>
> Question: How do I determine the default version of a module?
>
> I can parse the name out by doing a `module avail -d <tool_name>`, except that doing `module avail <tool_name>` always behaves like --starts-with is enabled, so for a tool named `py` it will also return information on tools named `pyc`.
>
> Is there a more straightforward way to get the default version of a module for use in a script?

_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Get default version of module

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

The "module show foo" command could help to inspect the modulefile version and the full path that would be resolved for some module specification. Also, since you're sourcing, see the Modules-provided Tcl command "module-info specified" (literal) for the name requested on the command line.

But what are you trying to do?


I figure your generator script scans your application INSTALL_DIR and in effect represents it in the form of virtual modulefiles. If your motivation is to reduce code length or duplication, you could instead represent each application version by an actual modulefile containing a few appropriate Tcl "set" commands, then source a "main" modulefile for handling. Working with explicitly set variables should help to keep the tree and code simple and maintainable.


With best regards,
Michael


> On Feb 25, 2021, at 20:34, John Peter Yamauchi (jyamauchi) <jya...@mi...> wrote:
> Hi all, 
> I’ve developed a system for my environment that auto-generates virtual modulefiles based on versions of tools that are installed.  The modules all point to a single modulefile that parses out the tool and version name from the name of the virtual module to set environment variables.
> 
> Loading these modules works without a hitch.  However, sourcing them causes issues, since I have to pass in the path to the generic module.  I am passing in the tool name, but I need to get the version name.
> 
> Question: How do I determine the default version of a module?
> 
> I can parse the name out by doing a `module avail -d <tool_name>`, except that doing `module avail <tool_name>` always behaves like --starts-with is enabled, so for a tool named `py` it will also return information on tools named `pyc`.
> 
> Is there a more straightforward way to get the default version of a module for use in a script?

[Modules] Get default version of module

[John P. Y. (jyamauchi) <jya...@mi...>]

Hi all,

I've developed a system for my environment that auto-generates virtual modulefiles based on versions of tools that are installed.  The modules all point to a single modulefile that parses out the tool and version name from the name of the virtual module to set environment variables.

Loading these modules works without a hitch.  However, sourcing them causes issues, since I have to pass in the path to the generic module.  I am passing in the tool name, but I need to get the version name.


Question: How do I determine the default version of a module?

I can parse the name out by doing a `module avail -d <tool_name>`, except that doing `module avail <tool_name>` always behaves like --starts-with is enabled, so for a tool named `py` it will also return information on tools named `pyc`.

Is there a more straightforward way to get the default version of a module for use in a script?


Thanks,

John Peter

[Modules] Modules 4.7.0 released

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

Hello All,

Modules 4.7.0 is here with many new stuff included, especially modules
can now be tagged or inherit tags that are reported on avail/list
sub-command output. It is as usual backward-compatible with previous
version 4 releases and primarily adds features and fixes bugs. Major
new features introduced in v4.7.0 since v4.6 are:

* Determining module implementation and version
* Symbolic version to designate module loaded version
* Module tags
* Hiding loaded modules
* Sticky modules
* Explaining avail/list output
* Configuring avail/list output

Details on these features 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-4.7.0.tar.gz

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

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

I would like to thanks Colin Marquardt, R.K. Owen and Anaïs Gaertner
for their contributions to this release. Thanks also to all of you who
improve Modules by reporting bugs or sharing new ideas.

Best regards,
Xavier

[Modules] Configuring avail/list output

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

Hello All,

Next Modules version will allow to control what content should be
reported in the output of the `avail` or `list` sub-commands.

To achieve so, new configuration options and command line switches are
introduced to define if you just want the module names to be reported
or if their properties (symbols, tags, key section, ...) should also
be part of the output.

More details and examples are available at:
https://modules.readthedocs.io/en/latest/MIGRATING.html#configuring-avail-list-output

Regards,
Xavier

Re: [Modules] Sticky modules

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

Hi,

Dependency mechanism could help to keep foo-wrapper at front, if this
module is set dependent of any other modules updating VAR. Stickiness
ensures that the foo-wrapper once loaded will be kept loaded.

You can also play with the "top priority value" concept exposed in
the following cookbook recipe:

https://modules.readthedocs.io/en/latest/cookbook/top-priority-values.html

With such hook, you can ensure a path added to or a value set to a
variable to stay at front.

Regards,
Xavier



On Wed, 2021-02-03 at 10:18 +0000, Foster, Martyn wrote:
> Hi,
> 
> I'm curious if this or a similar approach can cause a "stay at
> front" behaviour.
> 
> For example if Foo/1.0, Foo/2.0, and Foo-wrapper all prepend VAR
> but you would wish Foo-wrapper always to take precedent
> irrespective of load order (and without modification to Foo
> modulefiles).
> 
> Martyn
> 
> -----Original Message-----
> From: Xavier Delaruelle <xav...@gm...>
> Sent: 03 February 2021 06:41
> To: Environment Modules usage and discussion. <
> mod...@li...>
> Subject: [Modules] Sticky modules
> 
> 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.
> 
> Hello,
> 
> With next Modules release (v4.7), it will be possible to tag some
> modules *sticky* or *super-sticky* to glue them to the loaded
> environment.
> 
> See 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmodules.readthedocs.io%2Fen%2Flatest%2FMIGRATING.html%23sticky-modules&amp;data=04%7C01%7Cmartyn.foster%40atos.net%7C37164aac22434624052208d8c80eda46%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637479313409426778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GbgI5OnbOm1QhxsTLOFZN28fQRy6pH5J2bUFi24izVs%3D&amp;reserved=0
> 
> Regards,
> Xavier
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&amp;data=04%7C01%7Cmartyn.foster%40atos.net%7C37164aac22434624052208d8c80eda46%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637479313409426778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NwfrZjm1rivnDT1NnWx45%2FZlSqfEpF5aG5H0RPy817Y%3D&amp;reserved=0
> 
> Atos is a trading name used by the Atos group. The trading entity
> is registered in England and Wales: Atos IT Services UK Limited
> (registered number 01245534). The registered office is located at:
> Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The
> VAT No. is: GB232327983.
> 
> This e-mail and the documents attached are confidential and
> intended solely for the addressee and may contain confidential or
> privileged information. If you receive this e-mail in error, you
> are not authorised to copy, disclose, use or retain it. Please
> notify the sender immediately and delete this email from your
> systems. As emails may be intercepted, amended or lost, they are
> not secure. Atos therefore can accept no liability for any errors
> or their content. Although Atos endeavours to maintain a virus-free 
> network, we do not warrant that this transmission is virus-free and
> can accept no liability for any damages resulting from any virus
> transmitted. The risks are deemed to be accepted by everyone who
> communicates with Atos by email.
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Sticky modules

[Foster, M. <mar...@at...>]

Hi,

I'm curious if this or a similar approach can cause a "stay at front" behaviour.

For example if Foo/1.0, Foo/2.0, and Foo-wrapper all prepend VAR but you would wish Foo-wrapper always to take precedent irrespective of load order (and without modification to Foo modulefiles).

Martyn

-----Original Message-----
From: Xavier Delaruelle <xav...@gm...>
Sent: 03 February 2021 06:41
To: Environment Modules usage and discussion. <mod...@li...>
Subject: [Modules] Sticky modules

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.

Hello,

With next Modules release (v4.7), it will be possible to tag some modules *sticky* or *super-sticky* to glue them to the loaded environment.

See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmodules.readthedocs.io%2Fen%2Flatest%2FMIGRATING.html%23sticky-modules&amp;data=04%7C01%7Cmartyn.foster%40atos.net%7C37164aac22434624052208d8c80eda46%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637479313409426778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GbgI5OnbOm1QhxsTLOFZN28fQRy6pH5J2bUFi24izVs%3D&amp;reserved=0

Regards,
Xavier


_______________________________________________
Modules-interest mailing list
Mod...@li...
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&amp;data=04%7C01%7Cmartyn.foster%40atos.net%7C37164aac22434624052208d8c80eda46%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637479313409426778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NwfrZjm1rivnDT1NnWx45%2FZlSqfEpF5aG5H0RPy817Y%3D&amp;reserved=0

Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.

[Modules] Sticky modules

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

Hello,

With next Modules release (v4.7), it will be possible to tag some
modules *sticky* or *super-sticky* to glue them to the loaded
environment.

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

Regards,
Xavier