modules-interest — Discussion forum for modules usage.

Re: [Modules] Set a module "family provider" as a prerequisite?

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

Hi Adrien,

To cover the need you express, I think a new modulefile Tcl command
`provide` should be introduced.

I have created an issue for that: https://github.com/cea-hpc/modules/issues/539

I currently plan to land such new feature for 5.6 (so after 5.5)

Best regards,
Xavier

Le ven. 26 avr. 2024 à 10:44, Adrien COTTE - Groupe EOLEN
<adr...@eo...> a écrit :
>
> Hi Xavier,
>
> The module family feature is really cool, but not enough in my situation
> (I guess).
>
> My module nvhpc provides a certain version of CUDA.
> For example, "nvhpc/24.3" provides CUDA-12.3 and "nvhpc/21.7" provides
> CUDA-11.4.
> And my modules "cuda-toolkit/<version>" provide CUDA-<version>.
>
> It's the same issue with "python3/3.11.4" and "anaconda3/2023.09" which
> provide Python3.11.
> But, "intelpython/24.1" provides Python3.9.
>
> So, if i'm right, I have to combine family with several conflicts,
> example with "nvhpc/24.3":
>
> #%Module
>
> family CUDA-12.3
> conflict CUDA-11.8
> conflict CUDA-11.7
> conflict CUDA-11.6
> conflict CUDA-11.5
> conflict CUDA-11.4
> conflict CUDA-11.3
> conflict CUDA-11.2
> conflict CUDA-11.1
> conflict CUDA-11.0
>
> Any way to specify a sort of "sub family" or "family version"?
> Maybe I miss something, what do you think about my use case?
>
> Best,
> Adrien
>
> note: my modules are in lowercase, my families are in uppercase
>
> ________________________________
> De : Adrien COTTE - Groupe EOLEN <adr...@eo...>
> Envoyé : samedi 20 avril 2024 à 09:49
> À : Environment Modules usage and discussion.
> Objet : Re: [Modules] Set a module "family provider" as a prerequisite?
>
> Thanks, gonna give a try!
> ________________________________
> From: Xavier Delaruelle <xav...@gm...>
> Sent: Saturday, April 20, 2024 7:53:18 AM
> To: Environment Modules usage and discussion. <mod...@li...>
> Subject: Re: [Modules] Set a module "family provider" as a prerequisite?
>
> Hi Adrien,
>
> family and module-alias should help you there.
>
> family defines a conflict + a module alias when module is loaded. Add
> this line in your cuda-toolkit and nvhpc modulefiles:
>
>     family cuda
>
> then a module alias shoud be added to find the default "cuda" module.
> Add the following command to the global or modulepath-specific
> .modulerc file:
>
>     module-alias cuda cuda-toolkit/<version>
>
> you can now update all modulefiles requiring either cuda-toolkit or
> nvhpc to make them requiring cuda:
>
>     prereq cuda
>
> I have tested this on my side and it seems to work well:
>
> $ ml app
> Loading app/1
>   Loading requirement: cuda-toolkit/1
>
> $ ml switch cuda-toolkit nvhpc
> Switching from cuda-toolkit/1 to nvhpc/1
>   Unloading dependent: app/1
>   Reloading dependent: app/1
>
> I am quite interested to know if you find some issues or corner cases
> with this solution.
>
> Best regards,
> Xavier
>
> Le ven. 19 avr. 2024 à 12:58, Adrien COTTE - Groupe EOLEN
> <adr...@eo...> a écrit :
> >
> > Hi,
> >
> > I have a module with à prereq "cuda-toolkit" or "nvhpc".
> >
> > So here is my prereq line:
> >
> > %Module
> > prereq cuda-toolkit nvhpc
> >
> > But, is it possible to declare my modules to be a sort of "cuda provider"?
> >
> > So i juste have to declare "prereq cuda" or "prereq --provider cuda" in my module?
> >
> > In fact, it's not just about cuda. I have some python modules too: intelpython, python3 and anaconda.
> >
> > I would like to set them as "python3.10" providers.
> >
> > I hope my ask in clear, if not please tell me.
> >
> > 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] Hierarchical report of available modules

[Angel de V. <ang...@ia...>]

Hello,

Thanks Paul and Xavier for your comments.

But I think the current options provided by "module" are not sufficient
for what I wanted to achieve. The idea is to give our users (some of
which are very new to "modules") a very easy and clear view of all the
packages we provide at our institution. We already have a webpage
describing them, organized by categories, and I wanted to be able to
somehow replicate the same structure with the command "module avail". In
case the mail broke all the lines, here you can see properly the output
structure after my changes: https://pastecode.io/s/955wj58p

> There currently are 3 ways to achieve hierarchical organization:
> * using specific modulepaths and enabling/disabling them on demand
> * playing with module visibility: hide modules that are not useful by
> default, show them if one specific module is loaded
> * module variants: 1 modulefile many variations of it

I knew these (and have used all except the variants, I'll give it a go),
but for very new users to "modules" I wanted to try something that does
not hide or disables anything by default, or that the user has to issue
some command to show some extra modules, etc. because they are going to
get confused (I know it is easy, but trust me, I know our users :-)). I
think they will prefer (though not sure yet) if all modules are shown,
but with a nice structure so they can find the relevant one quickly.

> As Paul suggest, there is also the approach to limit the view to the
> default (or latest) module version.

Yes, we use this one as well, but we have many different packages, not
many versions of each, so this cuts very little in our output (plus only
makes it shorter, not structured)./

> Based on your explanation and example, it may be interesting to add a
> "group" feature to specifically sort modules of a given modulepath.
> Group could be defined in .modulerc files with a new command
> (module-group for instance). One may decide to view all the modules
> sorted by group or not, thanks to the "avail_output" configuration
> option.

Yes, a "group" feature where you specify a hierarchy to be shown would
be ideal. My changes were attempting something similar, in which I give
for each modulepath a label and an indentation, so that I can create
"module avail" output in a more organized and personalized way.

Cheers,
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Tel.: +34 922-605-747
---------------------------------------------------------------------------------------------
AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal
DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information:  https://www.iac.es/en/disclaimer

Re: [Modules] Hierarchical report of available modules

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

Hello Angel,

There currently are 3 ways to achieve hierarchical organization:
* using specific modulepaths and enabling/disabling them on demand
* playing with module visibility: hide modules that are not useful by
default, show them if one specific module is loaded
* module variants: 1 modulefile many variations of it

As Paul suggest, there is also the approach to limit the view to the
default (or latest) module version.

Based on your explanation and example, it may be interesting to add a
"group" feature to specifically sort modules of a given modulepath.
Group could be defined in .modulerc files with a new command
(module-group for instance). One may decide to view all the modules
sorted by group or not, thanks to the "avail_output" configuration
option.

Cheers,
Xavier

Le ven. 6 sept. 2024 à 20:00, Angel de Vicente via Modules-interest
<mod...@li...> a écrit :
>
> Hello,
>
> at our institution we make availabe via modules a large (and increasing)
> number of packages. I wanted to experiment with organizing them
> hierarchically so that our users can find them easier. I looked around
> the documentation and the web and couldn't find a way to do it (please
> let me know if I missed something).
>
> In the meantime I changed the code to allow for this, so we can get a
> more user-friendly (I hope) list of modules (different indentation and
> separator characters for different group levels; empty supergroups like
> "Reduction of Astronomical Data", just grouping other levels). Below a
> small demo (I hope the e-mail doesn't break the lines).
>
> I didn't follow the project guidelines, and it is the first time I touch
> any Tcl code in decades, so I'm sure my styles leaves much to be
> desired. Hence, before I try to clean my code and try to make a PR out
> of it, I wanted to ask if this an option that you think might be
> interesting (if this is only useful to us, probably I just leave the
> spaguetti code as is).
>
> Cheers,
>
>
>
>
> $ ml av
> ====================================================== Reduction of Astronomical Data ======================================================
>
>      .......................................................... General Packages ...........................................................
>      casa/6.6.3  gildas/apr24a  heasoft/6.33.2
>
>      .......................................................... Specialized Tools ..........................................................
>      alfa/2.2             cloudy/23.01        galfit/3.0.5   healpix/3.82  molly/1.1.8   reduceme/5.0    sourcextractor++/0.22  visit/3.4.1
>      astrometry.net/0.94  daophot/2004.01.15  gnuastro/0.22  imfit/1.9.0   neat/2.3      rmodel/3.2.3    ultracam/9.16
>      bbarolo/1.7          ensemble/1.2        gnuastro/0.23  indexf/4.3    pamela/1.0.9  skymaker/4.2.0  vapor/3.9.1
>
> =================================================== Proposals and Observations Planning ====================================================
> starpos/0.0  xephem/4.2.0
>
> ====================================================== Display and Graphics Packages =======================================================
> aladin/12.060  ds9/8.5  fv/5.5.4  jhelioviewer/4.6.3  supermongo/2.4.36
>
> ======================================================= Editors and Text Processors ========================================================
> mendeley/2.111.0
>
> ======================================================== Programming and Libraries =========================================================
>
>      ............................................................... General ...............................................................
>      julia/1.10.2  julia/1.10.5  python/3.10  python/3.12
>
>      ................................................................ INTEL ................................................................
>      advisor/2024.1                compiler/2024.1.0       dnnl/3.4.0      intel_ipp_intel64/2021.11    oclfpga/2024.1.0
>      ccl/2021.12.0                 dal/2024.0.0            dpct/2024.1.0   intel_ippcp_intel64/2021.11  tbb/2021.12
>      compiler-intel-llvm/2024.1.0  debugger/2024.1.0       dpl/2022.5      mkl/2024.1                   vtune/2024.1
>      compiler-rt/2024.1.0          dev-utilities/2024.0.0  ifort/2024.1.0  mpi/2021.12
>
>      ............................................................... NVIDIA ................................................................
>      nvhpc-byo-compiler/24.3  nvhpc-hpcx-cuda12/24.3  nvhpc-nompi/24.3     nvhpc/24.3
>      nvhpc-hpcx-cuda11/24.3   nvhpc-hpcx/24.3         nvhpc-openmpi3/24.3
>
> Key:
> default-version  modulepath
>
>
> --
> Ángel de Vicente
>  Research Software Engineer (Supercomputing and BigData)
>  Tel.: +34 922-605-747
> ---------------------------------------------------------------------------------------------
> AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal
> DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information:  https://www.iac.es/en/disclaimer
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Hierarchical report of available modules

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

Might be useful.


Try this (already part of modules),
This is a more concise way to display the hierarchy:

	module avail --default
or:
	module avail -d

And even (for a straight list):
	module avail -d -t

(and they include the default module for each level).

Then you can use:

	module avail {path}

to list all the versions under a specific module path.


On 2024-09-06 12:21 PM, Angel de Vicente via Modules-interest wrote:
> Hello,
> 
> at our institution we make availabe via modules a large (and increasing)
> number of packages. I wanted to experiment with organizing them
> hierarchically so that our users can find them easier. I looked around
> the documentation and the web and couldn't find a way to do it (please
> let me know if I missed something).
> 
> In the meantime I changed the code to allow for this, so we can get a
> more user-friendly (I hope) list of modules (different indentation and
> separator characters for different group levels; empty supergroups like
> "Reduction of Astronomical Data", just grouping other levels). Below a
> small demo (I hope the e-mail doesn't break the lines).
> 
> I didn't follow the project guidelines, and it is the first time I touch
> any Tcl code in decades, so I'm sure my styles leaves much to be
> desired. Hence, before I try to clean my code and try to make a PR out
> of it, I wanted to ask if this an option that you think might be
> interesting (if this is only useful to us, probably I just leave the
> spaguetti code as is).
> 
> Cheers,
> 
> 
> 
> 
> $ ml av
> ====================================================== Reduction of Astronomical Data ======================================================
> 
>       .......................................................... General Packages ...........................................................
>       casa/6.6.3  gildas/apr24a  heasoft/6.33.2
> 
>       .......................................................... Specialized Tools ..........................................................
>       alfa/2.2             cloudy/23.01        galfit/3.0.5   healpix/3.82  molly/1.1.8   reduceme/5.0    sourcextractor++/0.22  visit/3.4.1
>       astrometry.net/0.94  daophot/2004.01.15  gnuastro/0.22  imfit/1.9.0   neat/2.3      rmodel/3.2.3    ultracam/9.16
>       bbarolo/1.7          ensemble/1.2        gnuastro/0.23  indexf/4.3    pamela/1.0.9  skymaker/4.2.0  vapor/3.9.1
> 
> =================================================== Proposals and Observations Planning ====================================================
> starpos/0.0  xephem/4.2.0
> 
> ====================================================== Display and Graphics Packages =======================================================
> aladin/12.060  ds9/8.5  fv/5.5.4  jhelioviewer/4.6.3  supermongo/2.4.36
> 
> ======================================================= Editors and Text Processors ========================================================
> mendeley/2.111.0
> 
> ======================================================== Programming and Libraries =========================================================
> 
>       ............................................................... General ...............................................................
>       julia/1.10.2  julia/1.10.5  python/3.10  python/3.12
> 
>       ................................................................ INTEL ................................................................
>       advisor/2024.1                compiler/2024.1.0       dnnl/3.4.0      intel_ipp_intel64/2021.11    oclfpga/2024.1.0
>       ccl/2021.12.0                 dal/2024.0.0            dpct/2024.1.0   intel_ippcp_intel64/2021.11  tbb/2021.12
>       compiler-intel-llvm/2024.1.0  debugger/2024.1.0       dpl/2022.5      mkl/2024.1                   vtune/2024.1
>       compiler-rt/2024.1.0          dev-utilities/2024.0.0  ifort/2024.1.0  mpi/2021.12
> 
>       ............................................................... NVIDIA ................................................................
>       nvhpc-byo-compiler/24.3  nvhpc-hpcx-cuda12/24.3  nvhpc-nompi/24.3     nvhpc/24.3
>       nvhpc-hpcx-cuda11/24.3   nvhpc-hpcx/24.3         nvhpc-openmpi3/24.3
> 
> Key:
> default-version  modulepath
> 
> 

-- 
--------------------------------------------------------
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] Hierarchical report of available modules

[Angel de V. <ang...@ia...>]

Hello,

at our institution we make availabe via modules a large (and increasing)
number of packages. I wanted to experiment with organizing them
hierarchically so that our users can find them easier. I looked around
the documentation and the web and couldn't find a way to do it (please
let me know if I missed something).

In the meantime I changed the code to allow for this, so we can get a
more user-friendly (I hope) list of modules (different indentation and
separator characters for different group levels; empty supergroups like
"Reduction of Astronomical Data", just grouping other levels). Below a
small demo (I hope the e-mail doesn't break the lines).

I didn't follow the project guidelines, and it is the first time I touch
any Tcl code in decades, so I'm sure my styles leaves much to be
desired. Hence, before I try to clean my code and try to make a PR out
of it, I wanted to ask if this an option that you think might be
interesting (if this is only useful to us, probably I just leave the
spaguetti code as is).

Cheers,




$ ml av
====================================================== Reduction of Astronomical Data ======================================================

     .......................................................... General Packages ...........................................................
     casa/6.6.3  gildas/apr24a  heasoft/6.33.2  

     .......................................................... Specialized Tools ..........................................................
     alfa/2.2             cloudy/23.01        galfit/3.0.5   healpix/3.82  molly/1.1.8   reduceme/5.0    sourcextractor++/0.22  visit/3.4.1  
     astrometry.net/0.94  daophot/2004.01.15  gnuastro/0.22  imfit/1.9.0   neat/2.3      rmodel/3.2.3    ultracam/9.16          
     bbarolo/1.7          ensemble/1.2        gnuastro/0.23  indexf/4.3    pamela/1.0.9  skymaker/4.2.0  vapor/3.9.1            

=================================================== Proposals and Observations Planning ====================================================
starpos/0.0  xephem/4.2.0  

====================================================== Display and Graphics Packages =======================================================
aladin/12.060  ds9/8.5  fv/5.5.4  jhelioviewer/4.6.3  supermongo/2.4.36  

======================================================= Editors and Text Processors ========================================================
mendeley/2.111.0  

======================================================== Programming and Libraries =========================================================

     ............................................................... General ...............................................................
     julia/1.10.2  julia/1.10.5  python/3.10  python/3.12  

     ................................................................ INTEL ................................................................
     advisor/2024.1                compiler/2024.1.0       dnnl/3.4.0      intel_ipp_intel64/2021.11    oclfpga/2024.1.0  
     ccl/2021.12.0                 dal/2024.0.0            dpct/2024.1.0   intel_ippcp_intel64/2021.11  tbb/2021.12       
     compiler-intel-llvm/2024.1.0  debugger/2024.1.0       dpl/2022.5      mkl/2024.1                   vtune/2024.1      
     compiler-rt/2024.1.0          dev-utilities/2024.0.0  ifort/2024.1.0  mpi/2021.12                  

     ............................................................... NVIDIA ................................................................
     nvhpc-byo-compiler/24.3  nvhpc-hpcx-cuda12/24.3  nvhpc-nompi/24.3     nvhpc/24.3  
     nvhpc-hpcx-cuda11/24.3   nvhpc-hpcx/24.3         nvhpc-openmpi3/24.3  

Key:
default-version  modulepath  


-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Tel.: +34 922-605-747
---------------------------------------------------------------------------------------------
AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal
DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information:  https://www.iac.es/en/disclaimer

Re: [Modules] set-alias when module load in interactive, but 'unalias: foo: not found' when unload in non-interactive

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

Hi Myles,

This issue has been fixed on Modules 5.4.0 that was released earlier this year.

Change has been made to execute unalias in any case but do not take
errors into account (as we want the alias to not be there, so if it is
already missing we are satisfied).

Now the following command is rendered for sh shell when processing an
unalias modulefile command:

unalias <name> 2>/dev/null || true;

Regards,
Xavier

Le mar. 27 août 2024 à 22:40, Myles <smp...@gm...> a écrit :
>
> Hi Xavier--
>
> I'm so sorry, I missed your reply somehow!
>
> I think you should just check for alias defined before trying to unalias.
> Ex, for bash:
>
> $ [[ $(type -t x) == "alias" ]] && echo "x is an alias"
> x is an alias
> $ alias x
> alias x='chmod +x'
> $ [[ $(type -t e) == "alias" ]] && echo "e is an alias"
>
> $ [[ $(type -t $the_alias) == "alias" ]] && unalias $the_alias
>
> Thanks for the quick response. Sorry again for missing it.
> --Myles
>
> On Wed, Dec 13, 2023 at 12:36 AM Xavier Delaruelle <xav...@gm...> wrote:
>>
>> Hi Myles,
>>
>> Many thanks for this issue report.
>>
>> I think I should adapt the shell code generated by "unset-alias", to only execute "unalias" shell command if alias is found defined.
>>
>> There is a way currently to avoid this error: let module propagate shell aliases to sub-shells. This can be achieved for interactive script execution by enabling "set_shell_startup" configuration option prior module command initialization [1].
>>
>> set_shell_startup defines the ENV and BASH_ENV variables and make them point to the Modules shell initialization script. With these env variables set, Modules shell init script is executed at start of the shell script you run. Loaded modules are refreshed which recreates shell alias in this sub-shell.
>>
>> $ cat test
>> #!/bin/bash
>> alias foo
>> module purge
>> $ module load foo
>> $ alias foo
>> alias foo='value'
>> $ bash test
>> test: line 2: alias: foo: not found
>> environment: line 4: unalias: foo: not found
>>
>> $ module purge
>> $ module config set_shell_startup 1
>> $ eval $(./modulecmd.tcl bash autoinit)
>> $ module load foo
>> $ bash test
>> alias foo='value'
>>
>> Regards,
>> Xavier
>>
>> [1] https://modules.readthedocs.io/en/latest/module.html#envvar-MODULES_SET_SHELL_STARTUP
>>
>>
>>
>>
>> Le mer. 13 déc. 2023 à 07:01, Myles <smp...@gm...> a écrit :
>>>
>>> I have a module with a set-alias that I load for my interactive shell. Let's say the alias is 'foo'.
>>>
>>> Then, when I run this script from that interactive environment:
>>> #!/bin/bash
>>> module purge
>>>
>>> I am getting:
>>> environment: line 26: unalias: foo: not found
>>>
>>> This is because the alias is not propagated to the child process. Shouldn't the unalias that happens during an unload check that the context shell is interactive?
>>>
>>> I am using EnvModules v5.3.1.
>>>
>>> I found this discussion, but I couldn't decide what to take away from it.
>>>
>>> https://sourceforge.net/p/modules/mailman/modules-interest/thread/546...@at.../
>>>
>>> Thanks!
>>> --Myles
>>> _______________________________________________
>>> 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] set-alias when module load in interactive, but 'unalias: foo: not found' when unload in non-interactive

[Myles <smp...@gm...>]

Hi Xavier--

I'm so sorry, I missed your reply somehow!

I think you should just check for alias defined before trying to unalias.
Ex, for bash:

$ [[ $(type -t x) == "alias" ]] && echo "x is an alias"
x is an alias
$ alias x
alias x='chmod +x'
$ [[ $(type -t e) == "alias" ]] && echo "e is an alias"

*$ [[ $(type -t $the_alias) == "alias" ]] && unalias $the_alias*

Thanks for the quick response. Sorry again for missing it.
--Myles

On Wed, Dec 13, 2023 at 12:36 AM Xavier Delaruelle <
xav...@gm...> wrote:

> Hi Myles,
>
> Many thanks for this issue report.
>
> I think I should adapt the shell code generated by "unset-alias", to only
> execute "unalias" shell command if alias is found defined.
>
> There is a way currently to avoid this error: let module propagate shell
> aliases to sub-shells. This can be achieved for interactive script
> execution by enabling "set_shell_startup" configuration option prior module
> command initialization [1].
>
> set_shell_startup defines the ENV and BASH_ENV variables and make them
> point to the Modules shell initialization script. With these env variables
> set, Modules shell init script is executed at start of the shell script you
> run. Loaded modules are refreshed which recreates shell alias in this
> sub-shell.
>
> $ cat test
> #!/bin/bash
> alias foo
> module purge
> $ module load foo
> $ alias foo
> alias foo='value'
> $ bash test
> test: line 2: alias: foo: not found
> environment: line 4: unalias: foo: not found
>
> $ module purge
> $ module config set_shell_startup 1
> $ eval $(./modulecmd.tcl bash autoinit)
> $ module load foo
> $ bash test
> alias foo='value'
>
> Regards,
> Xavier
>
> [1]
> https://modules.readthedocs.io/en/latest/module.html#envvar-MODULES_SET_SHELL_STARTUP
>
>
>
>
> Le mer. 13 déc. 2023 à 07:01, Myles <smp...@gm...> a écrit :
>
>> I have a module with a set-alias that I load for my interactive shell.
>> Let's say the alias is 'foo'.
>>
>> Then, when I run this script from that interactive environment:
>> #!/bin/bash
>> module purge
>>
>> I am getting:
>> environment: line 26: unalias: foo: not found
>>
>> This is because the alias is not propagated to the child process.
>> Shouldn't the unalias that happens during an unload check that the context
>> shell is interactive?
>>
>> I am using EnvModules v5.3.1.
>>
>> I found this discussion, but I couldn't decide what to take away from it.
>>
>> https://sourceforge.net/p/modules/mailman/modules-interest
>> /thread/546...@at.../
>>
>> Thanks!
>> --Myles
>> _______________________________________________
>> 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] Hide modulefiles but show container module directory

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

Hi Marc,

Here are some other leads that may be explored :

* -d and -L options help to get a concise output from avail
sub-command: 1 version per module, default one with -d and latest one
with -L. There is no way currently to make these filters permanent for
any avail command.

* maybe dirA, dirB, etc could be made modulepaths (the path you
provide to "module use" command): no-indepth approach should help as
the top level name should already give a clue to users. If not, it may
mean that this top level name is part of the modulepath rather than
part of the module name

* build modulerc file (or files) with "module-hide --soft" commands
for each module versions of dirX/subdirY combination except one
(default or latest version for instance). This solution should provide
the outcome you except, but may require extra work to maintain

Regards,
Xavier

Le mar. 13 août 2024 à 22:10, Marc Castells
<mar...@en...> a écrit :
>
> Thanks for the reply, Xavier
>
> avail-indepth almost works for me but If I understand correctly, it's only full-hierarchy visibility (indepth) or higher-level visibility only (no-indepth).
>
> Given my module structure with 3 hierarchical levels, for this to really work I would need to be able to go down two levels (no-indepth) or three levels (indepth). All I would like is to hide the leaf version numbers from within a module directory, but still show the two levels of hierarchy down to that level.
>
> Something like:
>
> (no leaf versions displayed)
> -----------------------------------------
> dirA/subdirX   dirA/subdirY   dirB/subdirZ
>
> (leaf versions displayed)
> -----------------------------------------
> dirA/subdirX/1   dirA/subdirX/2   dirA/subdirY/8   dirA/subdirY/9   dirB/subdirZ/3
>
> It is a shame that the indepth option is not configurable with the levels of hierarchy to show.
>
> Regards,
>
> Marc.
>
> -----Original Message-----
> From: Xavier Delaruelle
> Sent: Tuesday, August 13, 2024 7:26 PM
> To: Environment Modules usage and discussion. <mod...@li...>
> Subject: Re: [Modules] Hide modulefiles but show container module directory
>
> Hello Marc,
>
> As you would like to hide all module versions by default and only display the available module names, I suggest you look at the "avail_indepth" configuration option [1].
>
> This option is enabled by default, but if you disable it only the top directory level is reported on "module avail". You can list the versions of a given module by specifying it as argument (e.g., module avail foo/).
>
> Quick demo:
>
> ❯ module avail
> ---------------- /path/to/modulefiles ----------------
> bar/1  bar/2  foo/1  foo/2
>
> Key:
> modulepath
> ❯ module avail --no-indepth
> ---------------- /path/to/modulefiles ---------------- bar/  foo/
>
> Key:
> modulepath  directory/
> ❯ module config avail_indepth 0
> ❯ module avail
> ---------------- /path/to/modulefiles ---------------- bar/  foo/
>
> Key:
> modulepath  directory/
> ❯ module avail foo/
> ---------------- /path/to/modulefiles ----------------
> foo/1  foo/2
>
> Key:
> modulepath
>
> Regards,
> Xavier
>
> [1] https://modules.readthedocs.io/en/latest/module.html#mconfig-avail_indepth
>
> Le mar. 13 août 2024 à 17:00, Marc Castells <mar...@en...> a écrit :
> >
> > Hi,
> >
> > An example structure:
> >
> > + DIR_1
> >   + SUBDIR_A
> >      + 0.1
> >      + 0.2
> >      + 1.0
> >      + 2.0
> >      + ....
> >
> > DIR_1 is the path fed to the 'module use' command in the initrc file. The sub-directories inside it are expected to be recursively searched by the tool.
> >
> > I am trying to find a way to soft hide all individual modulefile versions inside SUBDIR_A in a module avail command but show the DIR_1/SUBDIR_A stub. The reason for this is that I have multiple SUBDIR_? (around 20), each with many modulefiles (from a few to 10s). The idea would be to use module avail to get a top level view of the available SUBDIR modules without the clutter inside each module directory. Regular users would simply invoke 'module load DIR_1/SUBDIR_A' and rely on default and/or current version specifier. For a finer selection within SUBDIR_A, the user would target 'module avail -a DIR_1/SUBDIR_A' and all the available versions would be displayed.
> >
> > I have tried the following with the module-hide feature but none have work:
> > a) module-hide -soft DIR_1/SUBDIR_A
> > b) module-hide -soft DIR_1/SUBDIR_A@<first_version>:<last_version>
> > c) module-hide -soft DIR_1/SUBDIR_A@:
> >
> > a) and b) hide DIR_1/SUBDIR_A entirely. c) does not hide anything and
> > all versions are displayed
> >
> > Is there a native way within the tool to support this functionality?
> >
> > Thanks
>
>
> _______________________________________________
> 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] Hide modulefiles but show container module directory

[Marc C. <mar...@en...>]

Thanks for the reply, Xavier

avail-indepth almost works for me but If I understand correctly, it's only full-hierarchy visibility (indepth) or higher-level visibility only (no-indepth).

Given my module structure with 3 hierarchical levels, for this to really work I would need to be able to go down two levels (no-indepth) or three levels (indepth). All I would like is to hide the leaf version numbers from within a module directory, but still show the two levels of hierarchy down to that level.

Something like:

(no leaf versions displayed)
-----------------------------------------
dirA/subdirX   dirA/subdirY   dirB/subdirZ

(leaf versions displayed)
-----------------------------------------
dirA/subdirX/1   dirA/subdirX/2   dirA/subdirY/8   dirA/subdirY/9   dirB/subdirZ/3

It is a shame that the indepth option is not configurable with the levels of hierarchy to show.

Regards,

Marc.

-----Original Message-----
From: Xavier Delaruelle
Sent: Tuesday, August 13, 2024 7:26 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Hide modulefiles but show container module directory

Hello Marc,

As you would like to hide all module versions by default and only display the available module names, I suggest you look at the "avail_indepth" configuration option [1].

This option is enabled by default, but if you disable it only the top directory level is reported on "module avail". You can list the versions of a given module by specifying it as argument (e.g., module avail foo/).

Quick demo:

❯ module avail
---------------- /path/to/modulefiles ----------------
bar/1  bar/2  foo/1  foo/2

Key:
modulepath
❯ module avail --no-indepth
---------------- /path/to/modulefiles ---------------- bar/  foo/

Key:
modulepath  directory/
❯ module config avail_indepth 0
❯ module avail
---------------- /path/to/modulefiles ---------------- bar/  foo/

Key:
modulepath  directory/
❯ module avail foo/
---------------- /path/to/modulefiles ----------------
foo/1  foo/2

Key:
modulepath

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/module.html#mconfig-avail_indepth

Le mar. 13 août 2024 à 17:00, Marc Castells <mar...@en...> a écrit :
>
> Hi,
>
> An example structure:
>
> + DIR_1
>   + SUBDIR_A
>      + 0.1
>      + 0.2
>      + 1.0
>      + 2.0
>      + ....
>
> DIR_1 is the path fed to the 'module use' command in the initrc file. The sub-directories inside it are expected to be recursively searched by the tool.
>
> I am trying to find a way to soft hide all individual modulefile versions inside SUBDIR_A in a module avail command but show the DIR_1/SUBDIR_A stub. The reason for this is that I have multiple SUBDIR_? (around 20), each with many modulefiles (from a few to 10s). The idea would be to use module avail to get a top level view of the available SUBDIR modules without the clutter inside each module directory. Regular users would simply invoke 'module load DIR_1/SUBDIR_A' and rely on default and/or current version specifier. For a finer selection within SUBDIR_A, the user would target 'module avail -a DIR_1/SUBDIR_A' and all the available versions would be displayed.
>
> I have tried the following with the module-hide feature but none have work:
> a) module-hide -soft DIR_1/SUBDIR_A
> b) module-hide -soft DIR_1/SUBDIR_A@<first_version>:<last_version>
> c) module-hide -soft DIR_1/SUBDIR_A@:
>
> a) and b) hide DIR_1/SUBDIR_A entirely. c) does not hide anything and
> all versions are displayed
>
> Is there a native way within the tool to support this functionality?
>
> Thanks


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

Re: [Modules] Hide modulefiles but show container module directory

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

That is an interesting option.

I should check if our users would be interested in the list working that way.

Individual users can turn it off (in bash/sh) with:
export MODULES_AVAIL_INDEPTH=0

(tested, and it works).

One (as in the person setting up a site - not something that should be included by default) could also define an alias (in bash/sh):
alias module-avail='module avail  --no-indepth'

(tested this as well).




On 2024-08-13 12:25 PM, Xavier Delaruelle wrote:
> Hello Marc,
> 
> As you would like to hide all module versions by default and only
> display the available module names, I suggest you look at the
> "avail_indepth" configuration option [1].
> 
> This option is enabled by default, but if you disable it only the top
> directory level is reported on "module avail". You can list the
> versions of a given module by specifying it as argument (e.g., module
> avail foo/).
> 
> Quick demo:
> 
> ❯ module avail
> ---------------- /path/to/modulefiles ----------------
> bar/1  bar/2  foo/1  foo/2
> 
> Key:
> modulepath
> ❯ module avail --no-indepth
> ---------------- /path/to/modulefiles ----------------
> bar/  foo/
> 
> Key:
> modulepath  directory/
> ❯ module config avail_indepth 0
> ❯ module avail
> ---------------- /path/to/modulefiles ----------------
> bar/  foo/
> 
> Key:
> modulepath  directory/
> ❯ module avail foo/
> ---------------- /path/to/modulefiles ----------------
> foo/1  foo/2
> 
> Key:
> modulepath
> 
> Regards,
> Xavier
> 
> [1] https://modules.readthedocs.io/en/latest/module.html#mconfig-avail_indepth
> 
> Le mar. 13 août 2024 à 17:00, Marc Castells
> <mar...@en...> a écrit :
>>
>> Hi,
>>
>> An example structure:
>>
>> + DIR_1
>>    + SUBDIR_A
>>       + 0.1
>>       + 0.2
>>       + 1.0
>>       + 2.0
>>       + ....
>>
>> DIR_1 is the path fed to the 'module use' command in the initrc file. The sub-directories inside it are expected to be recursively searched by the tool.
>>
>> I am trying to find a way to soft hide all individual modulefile versions inside SUBDIR_A in a module avail command but show the DIR_1/SUBDIR_A stub. The reason for this is that I have multiple SUBDIR_? (around 20), each with many modulefiles (from a few to 10s). The idea would be to use module avail to get a top level view of the available SUBDIR modules without the clutter inside each module directory. Regular users would simply invoke 'module load DIR_1/SUBDIR_A' and rely on default and/or current version specifier. For a finer selection within SUBDIR_A, the user would target 'module avail -a DIR_1/SUBDIR_A' and all the available versions would be displayed.
>>
>> I have tried the following with the module-hide feature but none have work:
>> a) module-hide -soft DIR_1/SUBDIR_A
>> b) module-hide -soft DIR_1/SUBDIR_A@<first_version>:<last_version>
>> c) module-hide -soft DIR_1/SUBDIR_A@:
>>
>> a) and b) hide DIR_1/SUBDIR_A entirely. c) does not hide anything and all versions are displayed
>>
>> Is there a native way within the tool to support this functionality?
>>
>> Thanks
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] Hide modulefiles but show container module directory

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

Hello Marc,

As you would like to hide all module versions by default and only
display the available module names, I suggest you look at the
"avail_indepth" configuration option [1].

This option is enabled by default, but if you disable it only the top
directory level is reported on "module avail". You can list the
versions of a given module by specifying it as argument (e.g., module
avail foo/).

Quick demo:

❯ module avail
---------------- /path/to/modulefiles ----------------
bar/1  bar/2  foo/1  foo/2

Key:
modulepath
❯ module avail --no-indepth
---------------- /path/to/modulefiles ----------------
bar/  foo/

Key:
modulepath  directory/
❯ module config avail_indepth 0
❯ module avail
---------------- /path/to/modulefiles ----------------
bar/  foo/

Key:
modulepath  directory/
❯ module avail foo/
---------------- /path/to/modulefiles ----------------
foo/1  foo/2

Key:
modulepath

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/module.html#mconfig-avail_indepth

Le mar. 13 août 2024 à 17:00, Marc Castells
<mar...@en...> a écrit :
>
> Hi,
>
> An example structure:
>
> + DIR_1
>   + SUBDIR_A
>      + 0.1
>      + 0.2
>      + 1.0
>      + 2.0
>      + ....
>
> DIR_1 is the path fed to the 'module use' command in the initrc file. The sub-directories inside it are expected to be recursively searched by the tool.
>
> I am trying to find a way to soft hide all individual modulefile versions inside SUBDIR_A in a module avail command but show the DIR_1/SUBDIR_A stub. The reason for this is that I have multiple SUBDIR_? (around 20), each with many modulefiles (from a few to 10s). The idea would be to use module avail to get a top level view of the available SUBDIR modules without the clutter inside each module directory. Regular users would simply invoke 'module load DIR_1/SUBDIR_A' and rely on default and/or current version specifier. For a finer selection within SUBDIR_A, the user would target 'module avail -a DIR_1/SUBDIR_A' and all the available versions would be displayed.
>
> I have tried the following with the module-hide feature but none have work:
> a) module-hide -soft DIR_1/SUBDIR_A
> b) module-hide -soft DIR_1/SUBDIR_A@<first_version>:<last_version>
> c) module-hide -soft DIR_1/SUBDIR_A@:
>
> a) and b) hide DIR_1/SUBDIR_A entirely. c) does not hide anything and all versions are displayed
>
> Is there a native way within the tool to support this functionality?
>
> Thanks

[Modules] Hide modulefiles but show container module directory

[Marc C. <mar...@en...>]

Hi,

An example structure:

+ DIR_1
  + SUBDIR_A
     + 0.1
     + 0.2
     + 1.0
     + 2.0
     + ....

DIR_1 is the path fed to the 'module use' command in the initrc file. The sub-directories inside it are expected to be recursively searched by the tool.

I am trying to find a way to soft hide all individual modulefile versions inside SUBDIR_A in a module avail command but show the DIR_1/SUBDIR_A stub. The reason for this is that I have multiple SUBDIR_? (around 20), each with many modulefiles (from a few to 10s). The idea would be to use module avail to get a top level view of the available SUBDIR modules without the clutter inside each module directory. Regular users would simply invoke 'module load DIR_1/SUBDIR_A' and rely on default and/or current version specifier. For a finer selection within SUBDIR_A, the user would target 'module avail -a DIR_1/SUBDIR_A' and all the available versions would be displayed.

I have tried the following with the module-hide feature but none have work:
a) module-hide -soft DIR_1/SUBDIR_A
b) module-hide -soft DIR_1/SUBDIR_A@<first_version>:<last_version>
c) module-hide -soft DIR_1/SUBDIR_A@:

a) and b) hide DIR_1/SUBDIR_A entirely. c) does not hide anything and all versions are displayed

Is there a native way within the tool to support this functionality?

Thanks

Re: [Modules] sh-to-mod

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

Hello Glenn,

This is not possible with current version. But such feature could be
easily added. I have created a feature request for that [1]

I have written some guidelines if someone wants to handle the
development of this feature request (please ping me on the github
issue ticket if one need more information to contribute).

Regards,
Xavier

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

Le jeu. 18 juil. 2024 à 19:18, Glenn Johnson <gle...@ou...> a écrit :
>
> Is it possible to use the --ignore flag for the sh-to-mod subcommand, like how the source-sh modulefile command does?
>
> Thanks
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] sh-to-mod

[Glenn J. <gle...@ou...>]

Is it possible to use the --ignore flag for the sh-to-mod subcommand, like how the source-sh modulefile command does?

Thanks

[Modules] Logging activity

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

Dear All,

The ability to log module command activity will be available out of
the box starting version 5.5. This feature relies on two new
configuration options:

* logger: the command run to transmit messages to the log system
* logged_events: list of module event to log

See details and examples at:

https://modules.readthedocs.io/en/latest/MIGRATING.html#logging-activity

Regards,
Xavier

[Modules] New lsb-release modulefile command

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

Hello All,

The "lsb-release" modulefile command is introduced for next Modules
version (5.5)

This command gets Linux Standard Base information like distribution id
or release. It may help if you want to adapt the environment changes
of your modulefiles depending on the underlying OS.

See command man at:
https://modules.readthedocs.io/en/latest/modulefile.html#mfcmd-lsb-release

Regards,
Xavier

[Modules] New hide_auto_loaded option

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

Dear All,

The "hide_auto_loaded" configuration will be introduced on next
Modules release (v5.5).

https://modules.readthedocs.io/en/latest/module.html#mconfig-hide_auto_loaded

When enabled, all modules that are auto loaded are automatically
tagged hidden-loaded, not to show them by default on "module list"
output (unless --all option is set).

Regards,
Xavier

Re: [Modules] Switch between versions

[Glenn J. <gle...@ou...>]

I apologize for the delayed reply. I had to dig the replies out of my spam folder, so I did not see them right away. Thank you for fixing this so quickly.
________________________________
From: Xavier Delaruelle <xav...@gm...>
Sent: Monday, June 10, 2024 11:28 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Switch between versions

Hello Glenn,

The issue you detect comes from the broken *versions* modulefiles that
are generated since Modules 4.2 when --enable-versioning installation
option is set. Modules 4.2 introduced the module consistency and
automated module handling and since then the use of "module unload"
command in modulefiles means declaring a conflict toward the module to
unload.

Starting Modules 4.7, the --not-req option is available on "module
unload" to avoid this implicit conflict declaration.

I have made an issue and a fix for it:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcea-hpc%2Fmodules%2Fissues%2F531&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375358499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0xB7tZSiQwS58jYCYOr1LHlmFcSw8ZB6NgTeYDfOGw4%3D&reserved=0<https://github.com/cea-hpc/modules/issues/531>

Existing versions modulefiles for Modules version above 4.6 should be
updated to add the --not-req option to the module unload commands. The
following shell script should help to fix these modulefiles (replace
/usr/local/Modules/versions by the location where the versions
modulefiles are located on your setup):

for i in /usr/local/Modules/versions/*; do
    version=$(basename "$i")
    version=$i
    major=${version:0:1}
    minor=${version:2:1}
    if [[ "$major" -gt 4 || ("$major" -eq 4 && "$minor" -gt 6) ]]; then
        sed -i "s|module unload|module unload --not-req|" "$i"
    fi
done

Regards,
Xavier

Le jeu. 6 juin 2024 à 16:07, Paul Markfort <pau...@gm...> a écrit :
>
> I should point out, that we don't use the actual version switching system.
> But I do use versioning to make it easier to upgrade (the versioning chooses the version specific installation folder for configure).
>
> Notes: We have the modules installed to a network location (/stage/site/modules/ )
>         common is where the actual module files are:
>         MODULEPATH=/h/paulfm/unix/my.etc/modules:/stage/site/modules/common
>
> I install the new version, then change /stage/site/modules/default to point to the installation folder of the new version.
> I have a way of testing the new version before I do this.
> This makes upgrading the modules system very easy, and I have a way to revert if a problem is found in the newer version
> (I have not had to do this in quite some time).
>
>
> A listing will probably make this clearer ( /stage/site is a network share - 3.1.6 is the last binary version we used):
>
> - $ ls -al /stage/site/modules/
> total 27
> drwxr-xr-x 19 root root       22 Mar 27 15:27 .
> drwxr-xr-x 12 root root       12 Jun 29  2023 ..
> drwxr-xr-x  6 root root        6 Apr  4  2005 3.1.6
> lrwxrwxrwx  1 root root       16 Feb 16  2017 3.2.10 -> 3.2.10.tcl.1.729
> drwxr-xr-x  7 root root        7 Nov 13  2016 3.2.10.tcl.1.147
> drwxr-xr-x  7 root root        7 Feb 16  2017 3.2.10.tcl.1.729
> drwxr-xr-x  6 root root        9 Oct 20  2017 4.0.0
> drwxr-xr-x  7 root root        8 Mar 14  2018 4.1.1
> drwxr-xr-x  7 root root        8 Sep 23  2018 4.1.4
> drwxr-xr-x  9 root root       10 Jul 31  2020 4.5.2
> drwxr-xr-x 10 root root       11 Jul  9  2021 4.7.1
> drwxr-xr-x 10 root root       11 Jul 14  2021 4.8.0
> drwxr-xr-x 10 root root       11 Sep 13  2021 5.0.0
> drwxr-xr-x 10 root root       11 Oct 18  2021 5.0.1
> drwxr-xr-x 10 root root       11 May  9  2022 5.1.0
> drwxr-xr-x 10 root root       11 Nov  9  2022 5.2.0
> drwxr-xr-x 10 root root       11 Jul 10  2023 5.3.1
> drwxr-xr-x 10 root root       11 Mar  8 13:11 5.4.0
> drwxr-sr-x 25 root root       27 Dec 29  2020 common
> lrwxrwxrwx  1 root root        5 Mar 27 15:27 default -> 5.4.0
> lrwxrwxrwx  1 root root        5 Aug 21  2023 default.old -> 5.3.1
> drwxr-xr-x  3 root root       13 Mar  8 13:07 versions
>
>
> And, I should thank the module versioned install for showing me the advantages of this way of doing installs.
> I have been using versioned installs (since before 2005) on all sorts of software that I install by hand or from source.
> This includes things like samba, cups, dhcpd (and now kea-dhcp), bind, and several versions of client software (on Linux and Windows).
>
> Here is an example on my home machine (I install to /usr/added):
> - $ ls -al /usr/added/
> total 32
> drwxr-xr-x  8 root root 4096 Apr 12 19:46 .
> drwxr-xr-x 16 root root 4096 Feb  8 11:07 ..
> lrwxrwxrwx  1 root root   21 Apr 12 19:02 bind -> bind.ver/bind-9.18.25
> drwxr-xr-x  4 root root 4096 Apr 12 19:02 bind.ver
> lrwxrwxrwx  1 root root   19 Sep 22  2023 cups -> cups.ver/cups-2.4.7
> drwxr-xr-x  4 root root 4096 Sep 22  2023 cups.ver
> lrwxrwxrwx  1 root root   22 Apr  7  2023 dhcp -> dhcp.ver/dhcp-4.4.3-P1
> drwxr-xr-x  4 root root 4096 Apr  7  2023 dhcp.ver
> lrwxrwxrwx  1 root root   22 Dec 18 16:36 kea-dhcp -> kea-dhcp.ver/kea-2.4.1
> drwxr-xr-x  4 root root 4096 Dec 18 16:36 kea-dhcp.ver
> lrwxrwxrwx  1 root root   22 Apr 12 19:46 samba -> samba.ver/samba-4.20.0
> drwxr-xr-x  4 root root 4096 Apr 12 19:33 samba.ver
> drwxr-xr-x  8 root root 4096 Mar 12 16:07 SITE
>
>
>
> On 2024-06-06 8:36 AM, Xavier Delaruelle wrote:
> > Thanks Paul for your input.
> >
> > It seems this versioning mechanism does not work anymore with
> > automated module handling feature.
> >
> > I will look at how things could be adapted to make versioning work again.
> >
> > Regards,
> > Xavier
> >
> > Le mer. 5 juin 2024 à 17:34, Paul Markfort <pau...@gm...> a écrit :
> >>
> >> How do you switch module versions?
> >>
> >> So far (starting with 5.4.0 - in bash) I find this sort of works:
> >>
> >> - $ echo $SHELL
> >> /bin/bash
> >>
> >> - $ module --version
> >> Modules Release 5.4.0 (2024-02-20)
> >>
> >> - $ module load /stage/site/modules/5.3.1/modulefiles/modules
> >>
> >> - $ . /stage/site/modules/5.3.1/init/bash
> >>
> >>
> >> But that misses a couple variables:
> >> - $ set |grep MODULE
> >> MODULESHOME=/stage/site/modules/5.3.1
> >> MODULES_CMD=/stage/site/modules/5.3.1/libexec/modulecmd.tcl
> >> MODULE_VERSION=5.4.0
> >> MODULE_VERSION_STACK=5.4.0
> >>
> >> But this then works:
> >> - $ module --version
> >> Modules Release 5.3.1 (2023-06-27)
> >>
> >>
> >> The files in /stage/site/modules/versions have a dependency for the modules module
> >> Which means one needs a generic version of this module (the one shipped with each version is module specific)
> >>
> >> This doesn't work at all:
> >>
> >> - $ module switch /stage/site/modules/versions/5.4.0/version  /stage/site/modules/versions/5.3.1
> >> Loading /stage/site/modules/versions/5.3.1
> >>     ERROR: Unable to locate a modulefile for 'modules'
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
> >>
> >> Even this fails:
> >>
> >> - $ module switch /stage/site/modules/versions/5.4.0/version
> >> Loading /stage/site/modules/versions/5.4.0/version
> >>     ERROR: Unable to locate a modulefile for 'modules'
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.4.0/version
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.4.0/version failed
> >>
> >>
> >> If I add a no-op module named modules to my set, then I get:
> >>
> >> - $  module switch /stage/site/modules/versions/5.4.0/version /stage/site/modules/versions/5.3.1
> >> Loading modules
> >>     ERROR: Conflicting /stage/site/modules/versions/5.3.1 is loading
> >>
> >> Loading /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
> >>
> >>
> >>
> >> On 2024-06-05 5:44 PM, Xavier Delaruelle wrote:
> >>> Hello Glenn,
> >>>
> >>> Could you give the command you type and the complete output obtained.
> >>> It will help to understand the issue you face. Are you using the
> >>> "module switch" command to change version?
> >>>
> >>> Regards,
> >>> Xavier
> >>>
> >>> Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
> >>>>
> >>>> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
> >>>>
> >>>> conflicting <version> is loading
> >>>>
> >>>> messages and load of requirement modules failed.
> >>>> _______________________________________________
> >>>> Modules-interest mailing list
> >>>> Mod...@li...
> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375372334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SAEsa59Z2CbeEdcbdY6NabqCi8X6DqVoUGzyuclCZTM%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/modules-interest>
> >>>
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375382381%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=R9mEqdgbunbgq%2FULBlbXPKtawtLih%2BNGVqHPqyGbIL8%3D&reserved=0<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: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaulfm.com%2F~paulfm%2F&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375389961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bERFCXCx1%2BZu9TwGifwvONtRU%2FGrpmx6HsyjjtYZQwI%3D&reserved=0<http://paulfm.com/~paulfm/>
> >> --------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375395525%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Dj24n0lGQVkqde8FqiGz%2Fif98gTiec9AMpckGC76mY8%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/modules-interest>
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375400270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s3GUmA6rDGvnnCVzG6TKAntMEx8r52vaMO%2BFopdJ1nk%3D&reserved=0<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: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaulfm.com%2F~paulfm%2F&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375404888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=M%2B4aS4eHWfNO8LspO1V27aWA0ux1%2FN9LQ5yRxXwwPSM%3D&reserved=0<http://paulfm.com/~paulfm/>
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375409402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sOzbrOMPeE8r0HzphlFbhJdH3P9iG0ZGJSRs6mz3U9M%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/modules-interest>


_______________________________________________
Modules-interest mailing list
Mod...@li...
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmodules-interest&data=05%7C02%7C%7C7f5501b9553f4d17ad7908dc89cf0152%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536769375413809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KHuVrCf%2Bh4lvzCbrtAVDZ1ol9W%2BaQWy4OHWEFIT0%2BzA%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/modules-interest>

Re: [Modules] code to select a default version?

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

Hello Mike,

.version files are Tcl script files that defines ModulesVersion. You
may access environment variable or use modulerc commands in these
scripts.

For instance to change the default version based on machine hostname:

#%Module
switch -- [uname nodename] {
    name1 - name2 - name3 {
        set ModulesVersion 1
    }
    default {
        set ModulesVersion 2
    }
}

If you want to switch over an environment variable, replace "[uname
nodename]" by "[getenv MY_ENV_VAR]".

By the way, I am adding the "lsb" command on next Modules version
(5.5) to be able to easily retrieve current Linux distribution name
and version.

Regards,
Xavier

Le lun. 10 juin 2024 à 20:52, Vanhorn, Mike
<mic...@wr...> a écrit :
>
>
>
> Is there a way to put some sort of code into the .version file so that you can have a different default based on, say, the operating system being used or some other factor?
>
>
>
> We have software, and depending on where the person logs in, the default version might be one of two different versions. That is, one set of workstations needs to run an older version, but some newer ones are able to run a more recent version of the software. So, it would be convenient if the .version file could set ModulesVersion differently based on which workstation the module was being loaded on.
>
>
>
> ---
>
> Mike VanHorn
>
> Senior Computer Systems Administrator
>
> College of Engineering and Computer Science
>
> Wright State University
>
> 265 Russ Engineering Center
>
> 937-775-5157
>
> mic...@wr...
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Switch between versions

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

Hello Glenn,

The issue you detect comes from the broken *versions* modulefiles that
are generated since Modules 4.2 when --enable-versioning installation
option is set. Modules 4.2 introduced the module consistency and
automated module handling and since then the use of "module unload"
command in modulefiles means declaring a conflict toward the module to
unload.

Starting Modules 4.7, the --not-req option is available on "module
unload" to avoid this implicit conflict declaration.

I have made an issue and a fix for it:
https://github.com/cea-hpc/modules/issues/531

Existing versions modulefiles for Modules version above 4.6 should be
updated to add the --not-req option to the module unload commands. The
following shell script should help to fix these modulefiles (replace
/usr/local/Modules/versions by the location where the versions
modulefiles are located on your setup):

for i in /usr/local/Modules/versions/*; do
    version=$(basename "$i")
    version=$i
    major=${version:0:1}
    minor=${version:2:1}
    if [[ "$major" -gt 4 || ("$major" -eq 4 && "$minor" -gt 6) ]]; then
        sed -i "s|module unload|module unload --not-req|" "$i"
    fi
done

Regards,
Xavier

Le jeu. 6 juin 2024 à 16:07, Paul Markfort <pau...@gm...> a écrit :
>
> I should point out, that we don't use the actual version switching system.
> But I do use versioning to make it easier to upgrade (the versioning chooses the version specific installation folder for configure).
>
> Notes: We have the modules installed to a network location (/stage/site/modules/ )
>         common is where the actual module files are:
>         MODULEPATH=/h/paulfm/unix/my.etc/modules:/stage/site/modules/common
>
> I install the new version, then change /stage/site/modules/default to point to the installation folder of the new version.
> I have a way of testing the new version before I do this.
> This makes upgrading the modules system very easy, and I have a way to revert if a problem is found in the newer version
> (I have not had to do this in quite some time).
>
>
> A listing will probably make this clearer ( /stage/site is a network share - 3.1.6 is the last binary version we used):
>
> - $ ls -al /stage/site/modules/
> total 27
> drwxr-xr-x 19 root root       22 Mar 27 15:27 .
> drwxr-xr-x 12 root root       12 Jun 29  2023 ..
> drwxr-xr-x  6 root root        6 Apr  4  2005 3.1.6
> lrwxrwxrwx  1 root root       16 Feb 16  2017 3.2.10 -> 3.2.10.tcl.1.729
> drwxr-xr-x  7 root root        7 Nov 13  2016 3.2.10.tcl.1.147
> drwxr-xr-x  7 root root        7 Feb 16  2017 3.2.10.tcl.1.729
> drwxr-xr-x  6 root root        9 Oct 20  2017 4.0.0
> drwxr-xr-x  7 root root        8 Mar 14  2018 4.1.1
> drwxr-xr-x  7 root root        8 Sep 23  2018 4.1.4
> drwxr-xr-x  9 root root       10 Jul 31  2020 4.5.2
> drwxr-xr-x 10 root root       11 Jul  9  2021 4.7.1
> drwxr-xr-x 10 root root       11 Jul 14  2021 4.8.0
> drwxr-xr-x 10 root root       11 Sep 13  2021 5.0.0
> drwxr-xr-x 10 root root       11 Oct 18  2021 5.0.1
> drwxr-xr-x 10 root root       11 May  9  2022 5.1.0
> drwxr-xr-x 10 root root       11 Nov  9  2022 5.2.0
> drwxr-xr-x 10 root root       11 Jul 10  2023 5.3.1
> drwxr-xr-x 10 root root       11 Mar  8 13:11 5.4.0
> drwxr-sr-x 25 root root       27 Dec 29  2020 common
> lrwxrwxrwx  1 root root        5 Mar 27 15:27 default -> 5.4.0
> lrwxrwxrwx  1 root root        5 Aug 21  2023 default.old -> 5.3.1
> drwxr-xr-x  3 root root       13 Mar  8 13:07 versions
>
>
> And, I should thank the module versioned install for showing me the advantages of this way of doing installs.
> I have been using versioned installs (since before 2005) on all sorts of software that I install by hand or from source.
> This includes things like samba, cups, dhcpd (and now kea-dhcp), bind, and several versions of client software (on Linux and Windows).
>
> Here is an example on my home machine (I install to /usr/added):
> - $ ls -al /usr/added/
> total 32
> drwxr-xr-x  8 root root 4096 Apr 12 19:46 .
> drwxr-xr-x 16 root root 4096 Feb  8 11:07 ..
> lrwxrwxrwx  1 root root   21 Apr 12 19:02 bind -> bind.ver/bind-9.18.25
> drwxr-xr-x  4 root root 4096 Apr 12 19:02 bind.ver
> lrwxrwxrwx  1 root root   19 Sep 22  2023 cups -> cups.ver/cups-2.4.7
> drwxr-xr-x  4 root root 4096 Sep 22  2023 cups.ver
> lrwxrwxrwx  1 root root   22 Apr  7  2023 dhcp -> dhcp.ver/dhcp-4.4.3-P1
> drwxr-xr-x  4 root root 4096 Apr  7  2023 dhcp.ver
> lrwxrwxrwx  1 root root   22 Dec 18 16:36 kea-dhcp -> kea-dhcp.ver/kea-2.4.1
> drwxr-xr-x  4 root root 4096 Dec 18 16:36 kea-dhcp.ver
> lrwxrwxrwx  1 root root   22 Apr 12 19:46 samba -> samba.ver/samba-4.20.0
> drwxr-xr-x  4 root root 4096 Apr 12 19:33 samba.ver
> drwxr-xr-x  8 root root 4096 Mar 12 16:07 SITE
>
>
>
> On 2024-06-06 8:36 AM, Xavier Delaruelle wrote:
> > Thanks Paul for your input.
> >
> > It seems this versioning mechanism does not work anymore with
> > automated module handling feature.
> >
> > I will look at how things could be adapted to make versioning work again.
> >
> > Regards,
> > Xavier
> >
> > Le mer. 5 juin 2024 à 17:34, Paul Markfort <pau...@gm...> a écrit :
> >>
> >> How do you switch module versions?
> >>
> >> So far (starting with 5.4.0 - in bash) I find this sort of works:
> >>
> >> - $ echo $SHELL
> >> /bin/bash
> >>
> >> - $ module --version
> >> Modules Release 5.4.0 (2024-02-20)
> >>
> >> - $ module load /stage/site/modules/5.3.1/modulefiles/modules
> >>
> >> - $ . /stage/site/modules/5.3.1/init/bash
> >>
> >>
> >> But that misses a couple variables:
> >> - $ set |grep MODULE
> >> MODULESHOME=/stage/site/modules/5.3.1
> >> MODULES_CMD=/stage/site/modules/5.3.1/libexec/modulecmd.tcl
> >> MODULE_VERSION=5.4.0
> >> MODULE_VERSION_STACK=5.4.0
> >>
> >> But this then works:
> >> - $ module --version
> >> Modules Release 5.3.1 (2023-06-27)
> >>
> >>
> >> The files in /stage/site/modules/versions have a dependency for the modules module
> >> Which means one needs a generic version of this module (the one shipped with each version is module specific)
> >>
> >> This doesn't work at all:
> >>
> >> - $ module switch /stage/site/modules/versions/5.4.0/version  /stage/site/modules/versions/5.3.1
> >> Loading /stage/site/modules/versions/5.3.1
> >>     ERROR: Unable to locate a modulefile for 'modules'
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
> >>
> >> Even this fails:
> >>
> >> - $ module switch /stage/site/modules/versions/5.4.0/version
> >> Loading /stage/site/modules/versions/5.4.0/version
> >>     ERROR: Unable to locate a modulefile for 'modules'
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.4.0/version
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.4.0/version failed
> >>
> >>
> >> If I add a no-op module named modules to my set, then I get:
> >>
> >> - $  module switch /stage/site/modules/versions/5.4.0/version /stage/site/modules/versions/5.3.1
> >> Loading modules
> >>     ERROR: Conflicting /stage/site/modules/versions/5.3.1 is loading
> >>
> >> Loading /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of requirement modules failed
> >>
> >> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
> >>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
> >>
> >>
> >>
> >> On 2024-06-05 5:44 PM, Xavier Delaruelle wrote:
> >>> Hello Glenn,
> >>>
> >>> Could you give the command you type and the complete output obtained.
> >>> It will help to understand the issue you face. Are you using the
> >>> "module switch" command to change version?
> >>>
> >>> Regards,
> >>> Xavier
> >>>
> >>> Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
> >>>>
> >>>> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
> >>>>
> >>>> conflicting <version> is loading
> >>>>
> >>>> messages and load of requirement modules failed.
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>
> >> --
> >> --------------------------------------------------------
> >> The views and opinions expressed above are strictly
> >> those of the author(s).  The content of this message has
> >> not been reviewed nor approved by any entity whatsoever.
> >> --------------------------------------------------------
> >> Paul FM         Info: http://paulfm.com/~paulfm/
> >> --------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> --------------------------------------------------------
> The views and opinions expressed above are strictly
> those of the author(s).  The content of this message has
> not been reviewed nor approved by any entity whatsoever.
> --------------------------------------------------------
> Paul FM         Info: http://paulfm.com/~paulfm/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] code to select a default version?

[Vanhorn, M. <mic...@wr...>]

Is there a way to put some sort of code into the .version file so that you can have a different default based on, say, the operating system being used or some other factor?

We have software, and depending on where the person logs in, the default version might be one of two different versions. That is, one set of workstations needs to run an older version, but some newer ones are able to run a more recent version of the software. So, it would be convenient if the .version file could set ModulesVersion differently based on which workstation the module was being loaded on.

---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
mic...@wr...

Re: [Modules] Switch between versions

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

I should point out, that we don't use the actual version switching system.
But I do use versioning to make it easier to upgrade (the versioning chooses the version specific installation folder for configure).

Notes: We have the modules installed to a network location (/stage/site/modules/ )
        common is where the actual module files are:
        MODULEPATH=/h/paulfm/unix/my.etc/modules:/stage/site/modules/common

I install the new version, then change /stage/site/modules/default to point to the installation folder of the new version.
I have a way of testing the new version before I do this.
This makes upgrading the modules system very easy, and I have a way to revert if a problem is found in the newer version
(I have not had to do this in quite some time).


A listing will probably make this clearer ( /stage/site is a network share - 3.1.6 is the last binary version we used):

- $ ls -al /stage/site/modules/
total 27
drwxr-xr-x 19 root root       22 Mar 27 15:27 .
drwxr-xr-x 12 root root       12 Jun 29  2023 ..
drwxr-xr-x  6 root root        6 Apr  4  2005 3.1.6
lrwxrwxrwx  1 root root       16 Feb 16  2017 3.2.10 -> 3.2.10.tcl.1.729
drwxr-xr-x  7 root root        7 Nov 13  2016 3.2.10.tcl.1.147
drwxr-xr-x  7 root root        7 Feb 16  2017 3.2.10.tcl.1.729
drwxr-xr-x  6 root root        9 Oct 20  2017 4.0.0
drwxr-xr-x  7 root root        8 Mar 14  2018 4.1.1
drwxr-xr-x  7 root root        8 Sep 23  2018 4.1.4
drwxr-xr-x  9 root root       10 Jul 31  2020 4.5.2
drwxr-xr-x 10 root root       11 Jul  9  2021 4.7.1
drwxr-xr-x 10 root root       11 Jul 14  2021 4.8.0
drwxr-xr-x 10 root root       11 Sep 13  2021 5.0.0
drwxr-xr-x 10 root root       11 Oct 18  2021 5.0.1
drwxr-xr-x 10 root root       11 May  9  2022 5.1.0
drwxr-xr-x 10 root root       11 Nov  9  2022 5.2.0
drwxr-xr-x 10 root root       11 Jul 10  2023 5.3.1
drwxr-xr-x 10 root root       11 Mar  8 13:11 5.4.0
drwxr-sr-x 25 root root       27 Dec 29  2020 common
lrwxrwxrwx  1 root root        5 Mar 27 15:27 default -> 5.4.0
lrwxrwxrwx  1 root root        5 Aug 21  2023 default.old -> 5.3.1
drwxr-xr-x  3 root root       13 Mar  8 13:07 versions


And, I should thank the module versioned install for showing me the advantages of this way of doing installs.
I have been using versioned installs (since before 2005) on all sorts of software that I install by hand or from source.
This includes things like samba, cups, dhcpd (and now kea-dhcp), bind, and several versions of client software (on Linux and Windows).

Here is an example on my home machine (I install to /usr/added):
- $ ls -al /usr/added/
total 32
drwxr-xr-x  8 root root 4096 Apr 12 19:46 .
drwxr-xr-x 16 root root 4096 Feb  8 11:07 ..
lrwxrwxrwx  1 root root   21 Apr 12 19:02 bind -> bind.ver/bind-9.18.25
drwxr-xr-x  4 root root 4096 Apr 12 19:02 bind.ver
lrwxrwxrwx  1 root root   19 Sep 22  2023 cups -> cups.ver/cups-2.4.7
drwxr-xr-x  4 root root 4096 Sep 22  2023 cups.ver
lrwxrwxrwx  1 root root   22 Apr  7  2023 dhcp -> dhcp.ver/dhcp-4.4.3-P1
drwxr-xr-x  4 root root 4096 Apr  7  2023 dhcp.ver
lrwxrwxrwx  1 root root   22 Dec 18 16:36 kea-dhcp -> kea-dhcp.ver/kea-2.4.1
drwxr-xr-x  4 root root 4096 Dec 18 16:36 kea-dhcp.ver
lrwxrwxrwx  1 root root   22 Apr 12 19:46 samba -> samba.ver/samba-4.20.0
drwxr-xr-x  4 root root 4096 Apr 12 19:33 samba.ver
drwxr-xr-x  8 root root 4096 Mar 12 16:07 SITE



On 2024-06-06 8:36 AM, Xavier Delaruelle wrote:
> Thanks Paul for your input.
> 
> It seems this versioning mechanism does not work anymore with
> automated module handling feature.
> 
> I will look at how things could be adapted to make versioning work again.
> 
> Regards,
> Xavier
> 
> Le mer. 5 juin 2024 à 17:34, Paul Markfort <pau...@gm...> a écrit :
>>
>> How do you switch module versions?
>>
>> So far (starting with 5.4.0 - in bash) I find this sort of works:
>>
>> - $ echo $SHELL
>> /bin/bash
>>
>> - $ module --version
>> Modules Release 5.4.0 (2024-02-20)
>>
>> - $ module load /stage/site/modules/5.3.1/modulefiles/modules
>>
>> - $ . /stage/site/modules/5.3.1/init/bash
>>
>>
>> But that misses a couple variables:
>> - $ set |grep MODULE
>> MODULESHOME=/stage/site/modules/5.3.1
>> MODULES_CMD=/stage/site/modules/5.3.1/libexec/modulecmd.tcl
>> MODULE_VERSION=5.4.0
>> MODULE_VERSION_STACK=5.4.0
>>
>> But this then works:
>> - $ module --version
>> Modules Release 5.3.1 (2023-06-27)
>>
>>
>> The files in /stage/site/modules/versions have a dependency for the modules module
>> Which means one needs a generic version of this module (the one shipped with each version is module specific)
>>
>> This doesn't work at all:
>>
>> - $ module switch /stage/site/modules/versions/5.4.0/version  /stage/site/modules/versions/5.3.1
>> Loading /stage/site/modules/versions/5.3.1
>>     ERROR: Unable to locate a modulefile for 'modules'
>>     ERROR: Load of requirement modules failed
>>
>> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
>>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
>>
>> Even this fails:
>>
>> - $ module switch /stage/site/modules/versions/5.4.0/version
>> Loading /stage/site/modules/versions/5.4.0/version
>>     ERROR: Unable to locate a modulefile for 'modules'
>>     ERROR: Load of requirement modules failed
>>
>> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.4.0/version
>>     ERROR: Load of switched-on /stage/site/modules/versions/5.4.0/version failed
>>
>>
>> If I add a no-op module named modules to my set, then I get:
>>
>> - $  module switch /stage/site/modules/versions/5.4.0/version /stage/site/modules/versions/5.3.1
>> Loading modules
>>     ERROR: Conflicting /stage/site/modules/versions/5.3.1 is loading
>>
>> Loading /stage/site/modules/versions/5.3.1
>>     ERROR: Load of requirement modules failed
>>
>> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
>>     ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
>>
>>
>>
>> On 2024-06-05 5:44 PM, Xavier Delaruelle wrote:
>>> Hello Glenn,
>>>
>>> Could you give the command you type and the complete output obtained.
>>> It will help to understand the issue you face. Are you using the
>>> "module switch" command to change version?
>>>
>>> Regards,
>>> Xavier
>>>
>>> Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
>>>>
>>>> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
>>>>
>>>> conflicting <version> is loading
>>>>
>>>> messages and load of requirement modules failed.
>>>> _______________________________________________
>>>> 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
>>>
>>
>> --
>> --------------------------------------------------------
>> The views and opinions expressed above are strictly
>> those of the author(s).  The content of this message has
>> not been reviewed nor approved by any entity whatsoever.
>> --------------------------------------------------------
>> Paul FM         Info: http://paulfm.com/~paulfm/
>> --------------------------------------------------------
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] Switch between versions

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

Thanks Paul for your input.

It seems this versioning mechanism does not work anymore with
automated module handling feature.

I will look at how things could be adapted to make versioning work again.

Regards,
Xavier

Le mer. 5 juin 2024 à 17:34, Paul Markfort <pau...@gm...> a écrit :
>
> How do you switch module versions?
>
> So far (starting with 5.4.0 - in bash) I find this sort of works:
>
> - $ echo $SHELL
> /bin/bash
>
> - $ module --version
> Modules Release 5.4.0 (2024-02-20)
>
> - $ module load /stage/site/modules/5.3.1/modulefiles/modules
>
> - $ . /stage/site/modules/5.3.1/init/bash
>
>
> But that misses a couple variables:
> - $ set |grep MODULE
> MODULESHOME=/stage/site/modules/5.3.1
> MODULES_CMD=/stage/site/modules/5.3.1/libexec/modulecmd.tcl
> MODULE_VERSION=5.4.0
> MODULE_VERSION_STACK=5.4.0
>
> But this then works:
> - $ module --version
> Modules Release 5.3.1 (2023-06-27)
>
>
> The files in /stage/site/modules/versions have a dependency for the modules module
> Which means one needs a generic version of this module (the one shipped with each version is module specific)
>
> This doesn't work at all:
>
> - $ module switch /stage/site/modules/versions/5.4.0/version  /stage/site/modules/versions/5.3.1
> Loading /stage/site/modules/versions/5.3.1
>    ERROR: Unable to locate a modulefile for 'modules'
>    ERROR: Load of requirement modules failed
>
> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
>    ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
>
> Even this fails:
>
> - $ module switch /stage/site/modules/versions/5.4.0/version
> Loading /stage/site/modules/versions/5.4.0/version
>    ERROR: Unable to locate a modulefile for 'modules'
>    ERROR: Load of requirement modules failed
>
> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.4.0/version
>    ERROR: Load of switched-on /stage/site/modules/versions/5.4.0/version failed
>
>
> If I add a no-op module named modules to my set, then I get:
>
> - $  module switch /stage/site/modules/versions/5.4.0/version /stage/site/modules/versions/5.3.1
> Loading modules
>    ERROR: Conflicting /stage/site/modules/versions/5.3.1 is loading
>
> Loading /stage/site/modules/versions/5.3.1
>    ERROR: Load of requirement modules failed
>
> Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
>    ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed
>
>
>
> On 2024-06-05 5:44 PM, Xavier Delaruelle wrote:
> > Hello Glenn,
> >
> > Could you give the command you type and the complete output obtained.
> > It will help to understand the issue you face. Are you using the
> > "module switch" command to change version?
> >
> > Regards,
> > Xavier
> >
> > Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
> >>
> >> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
> >>
> >> conflicting <version> is loading
> >>
> >> messages and load of requirement modules failed.
> >> _______________________________________________
> >> 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
> >
>
> --
> --------------------------------------------------------
> The views and opinions expressed above are strictly
> those of the author(s).  The content of this message has
> not been reviewed nor approved by any entity whatsoever.
> --------------------------------------------------------
> Paul FM         Info: http://paulfm.com/~paulfm/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Switch between versions

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

How do you switch module versions?

So far (starting with 5.4.0 - in bash) I find this sort of works:

- $ echo $SHELL
/bin/bash

- $ module --version
Modules Release 5.4.0 (2024-02-20)

- $ module load /stage/site/modules/5.3.1/modulefiles/modules

- $ . /stage/site/modules/5.3.1/init/bash


But that misses a couple variables:
- $ set |grep MODULE
MODULESHOME=/stage/site/modules/5.3.1
MODULES_CMD=/stage/site/modules/5.3.1/libexec/modulecmd.tcl
MODULE_VERSION=5.4.0
MODULE_VERSION_STACK=5.4.0

But this then works:
- $ module --version
Modules Release 5.3.1 (2023-06-27)


The files in /stage/site/modules/versions have a dependency for the modules module
Which means one needs a generic version of this module (the one shipped with each version is module specific)

This doesn't work at all:

- $ module switch /stage/site/modules/versions/5.4.0/version  /stage/site/modules/versions/5.3.1
Loading /stage/site/modules/versions/5.3.1
   ERROR: Unable to locate a modulefile for 'modules'
   ERROR: Load of requirement modules failed

Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
   ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed

Even this fails:

- $ module switch /stage/site/modules/versions/5.4.0/version
Loading /stage/site/modules/versions/5.4.0/version
   ERROR: Unable to locate a modulefile for 'modules'
   ERROR: Load of requirement modules failed

Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.4.0/version
   ERROR: Load of switched-on /stage/site/modules/versions/5.4.0/version failed


If I add a no-op module named modules to my set, then I get:

- $  module switch /stage/site/modules/versions/5.4.0/version /stage/site/modules/versions/5.3.1
Loading modules
   ERROR: Conflicting /stage/site/modules/versions/5.3.1 is loading

Loading /stage/site/modules/versions/5.3.1
   ERROR: Load of requirement modules failed

Switching from /stage/site/modules/versions/5.4.0/version to /stage/site/modules/versions/5.3.1
   ERROR: Load of switched-on /stage/site/modules/versions/5.3.1 failed



On 2024-06-05 5:44 PM, Xavier Delaruelle wrote:
> Hello Glenn,
> 
> Could you give the command you type and the complete output obtained.
> It will help to understand the issue you face. Are you using the
> "module switch" command to change version?
> 
> Regards,
> Xavier
> 
> Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
>>
>> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
>>
>> conflicting <version> is loading
>>
>> messages and load of requirement modules failed.
>> _______________________________________________
>> 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
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] Switch between versions

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

Hello Glenn,

Could you give the command you type and the complete output obtained.
It will help to understand the issue you face. Are you using the
"module switch" command to change version?

Regards,
Xavier

Le mer. 5 juin 2024 à 15:12, Glenn Johnson <gle...@ou...> a écrit :
>
> I have set --enable-versioning for multiple installations of environment-modules. I cannot figure out how to switch between the versions though. I get
>
> conflicting <version> is loading
>
> messages and load of requirement modules failed.
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest