You can subscribe to this list here.
| 1996 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(14) |
Jul
(6) |
Aug
(7) |
Sep
(1) |
Oct
(16) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1997 |
Jan
(9) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 1998 |
Jan
(5) |
Feb
(5) |
Mar
(1) |
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(6) |
Oct
(8) |
Nov
|
Dec
(1) |
| 1999 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(2) |
Jul
|
Aug
(10) |
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(6) |
| 2000 |
Jan
(5) |
Feb
(19) |
Mar
(27) |
Apr
(22) |
May
(11) |
Jun
(1) |
Jul
|
Aug
(7) |
Sep
(3) |
Oct
(1) |
Nov
(13) |
Dec
(4) |
| 2001 |
Jan
(14) |
Feb
|
Mar
(5) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(19) |
Aug
(8) |
Sep
(4) |
Oct
(4) |
Nov
(9) |
Dec
(17) |
| 2002 |
Jan
(17) |
Feb
(11) |
Mar
(5) |
Apr
(17) |
May
(17) |
Jun
(7) |
Jul
(18) |
Aug
(10) |
Sep
(20) |
Oct
(30) |
Nov
(3) |
Dec
(2) |
| 2003 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(16) |
Jun
(35) |
Jul
(2) |
Aug
(4) |
Sep
(10) |
Oct
(45) |
Nov
(7) |
Dec
(13) |
| 2004 |
Jan
|
Feb
|
Mar
(3) |
Apr
(5) |
May
(3) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(34) |
Oct
(26) |
Nov
(32) |
Dec
|
| 2005 |
Jan
(11) |
Feb
(2) |
Mar
(6) |
Apr
(60) |
May
(21) |
Jun
(14) |
Jul
(3) |
Aug
(6) |
Sep
(6) |
Oct
(13) |
Nov
(10) |
Dec
(19) |
| 2006 |
Jan
(32) |
Feb
(36) |
Mar
(7) |
Apr
(24) |
May
(5) |
Jun
(10) |
Jul
(4) |
Aug
(17) |
Sep
(13) |
Oct
(12) |
Nov
(1) |
Dec
(7) |
| 2007 |
Jan
(21) |
Feb
(16) |
Mar
(19) |
Apr
(2) |
May
(15) |
Jun
(18) |
Jul
(6) |
Aug
(2) |
Sep
(33) |
Oct
(21) |
Nov
|
Dec
|
| 2008 |
Jan
(10) |
Feb
(6) |
Mar
(2) |
Apr
(6) |
May
|
Jun
(13) |
Jul
(7) |
Aug
(12) |
Sep
(22) |
Oct
(8) |
Nov
(1) |
Dec
(25) |
| 2009 |
Jan
(6) |
Feb
(9) |
Mar
(13) |
Apr
(15) |
May
(17) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(9) |
Oct
(28) |
Nov
(6) |
Dec
|
| 2010 |
Jan
(17) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(20) |
Jun
(3) |
Jul
(9) |
Aug
(18) |
Sep
(10) |
Oct
(8) |
Nov
(9) |
Dec
(2) |
| 2011 |
Jan
(9) |
Feb
(4) |
Mar
(9) |
Apr
(7) |
May
(9) |
Jun
(31) |
Jul
(9) |
Aug
(15) |
Sep
(17) |
Oct
(7) |
Nov
(31) |
Dec
(2) |
| 2012 |
Jan
(16) |
Feb
(14) |
Mar
(59) |
Apr
(36) |
May
(28) |
Jun
(17) |
Jul
(6) |
Aug
(12) |
Sep
(21) |
Oct
(38) |
Nov
(14) |
Dec
(8) |
| 2013 |
Jan
(22) |
Feb
(8) |
Mar
(16) |
Apr
(50) |
May
(8) |
Jun
(44) |
Jul
(22) |
Aug
(7) |
Sep
(6) |
Oct
(5) |
Nov
(10) |
Dec
(1) |
| 2014 |
Jan
(1) |
Feb
(4) |
Mar
(16) |
Apr
(11) |
May
(24) |
Jun
(22) |
Jul
(32) |
Aug
(5) |
Sep
(5) |
Oct
(3) |
Nov
(15) |
Dec
(6) |
| 2015 |
Jan
(1) |
Feb
(33) |
Mar
(10) |
Apr
(2) |
May
(2) |
Jun
(8) |
Jul
(14) |
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(14) |
Dec
(8) |
| 2016 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(8) |
Aug
(18) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(8) |
Mar
(32) |
Apr
(31) |
May
(23) |
Jun
(1) |
Jul
(7) |
Aug
(28) |
Sep
(17) |
Oct
(18) |
Nov
(16) |
Dec
(17) |
| 2018 |
Jan
(6) |
Feb
(26) |
Mar
(6) |
Apr
(15) |
May
(22) |
Jun
(11) |
Jul
(12) |
Aug
(28) |
Sep
(7) |
Oct
(22) |
Nov
(21) |
Dec
(10) |
| 2019 |
Jan
(12) |
Feb
(23) |
Mar
(4) |
Apr
(17) |
May
(29) |
Jun
(5) |
Jul
(15) |
Aug
(12) |
Sep
(21) |
Oct
(17) |
Nov
(9) |
Dec
(8) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(28) |
Apr
(2) |
May
(2) |
Jun
(9) |
Jul
(5) |
Aug
(2) |
Sep
(7) |
Oct
(5) |
Nov
(1) |
Dec
(7) |
| 2021 |
Jan
(5) |
Feb
(11) |
Mar
(6) |
Apr
(1) |
May
(10) |
Jun
(21) |
Jul
(21) |
Aug
(8) |
Sep
(4) |
Oct
(37) |
Nov
(4) |
Dec
|
| 2022 |
Jan
(27) |
Feb
|
Mar
(34) |
Apr
(41) |
May
(3) |
Jun
(18) |
Jul
(16) |
Aug
(5) |
Sep
(1) |
Oct
(3) |
Nov
(9) |
Dec
|
| 2023 |
Jan
(13) |
Feb
(2) |
Mar
(2) |
Apr
(18) |
May
(4) |
Jun
(9) |
Jul
(3) |
Aug
(3) |
Sep
(6) |
Oct
(6) |
Nov
(4) |
Dec
(3) |
| 2024 |
Jan
(8) |
Feb
(13) |
Mar
(1) |
Apr
(5) |
May
(4) |
Jun
(11) |
Jul
(3) |
Aug
(7) |
Sep
(5) |
Oct
(6) |
Nov
(9) |
Dec
(20) |
| 2025 |
Jan
(40) |
Feb
(27) |
Mar
(4) |
Apr
(2) |
May
(15) |
Jun
(14) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Paul M. <pau...@gm...> - 2024-08-13 18:19:44
|
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/ -------------------------------------------------------- |
|
From: Xavier D. <xav...@gm...> - 2024-08-13 17:26:13
|
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 |
|
From: Marc C. <mar...@en...> - 2024-08-13 14:59:45
|
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
|
|
From: Xavier D. <xav...@gm...> - 2024-07-19 15:41:29
|
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 |
|
From: Glenn J. <gle...@ou...> - 2024-07-18 17:17:52
|
Is it possible to use the --ignore flag for the sh-to-mod subcommand, like how the source-sh modulefile command does? Thanks |
|
From: Xavier D. <xav...@gm...> - 2024-07-16 12:02:33
|
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 |
|
From: Xavier D. <xav...@gm...> - 2024-06-21 05:15:46
|
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 |
|
From: Xavier D. <xav...@gm...> - 2024-06-13 05:50:39
|
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 |
|
From: Glenn J. <gle...@ou...> - 2024-06-13 00:39:18
|
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> |
|
From: Xavier D. <xav...@gm...> - 2024-06-11 05:32:17
|
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
|
|
From: Xavier D. <xav...@gm...> - 2024-06-11 04:28:37
|
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 |
|
From: Vanhorn, M. <mic...@wr...> - 2024-06-10 18:51:08
|
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... |
|
From: Paul M. <pau...@gm...> - 2024-06-06 14:06:31
|
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/
--------------------------------------------------------
|
|
From: Xavier D. <xav...@gm...> - 2024-06-06 13:36:48
|
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 |
|
From: Paul M. <pau...@gm...> - 2024-06-06 00:33:28
|
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/ -------------------------------------------------------- |
|
From: Xavier D. <xav...@gm...> - 2024-06-05 22:44:35
|
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 |
|
From: Glenn J. <gle...@ou...> - 2024-06-05 22:11:50
|
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. |
|
From: Laurent B. <lau...@ea...> - 2024-05-30 08:50:58
|
Hello, Xavier, Paul, many thanks for these explanations. Suggested workaround is fine for me. Best regards, Laurent. -----Message d'origine----- De : Xavier Delaruelle <xav...@gm...> Envoyé : mercredi 29 mai 2024 06:29 À : Environment Modules usage and discussion. <mod...@li...> Objet : Re: [Modules] difference on MANPATH for tcsh between v3.2 vs v5.4 Hello Laurent, There were a specific treatment for MANPATH on Modules 3.2 that initialized it to a value defined at compilation when changing this path. There is no more such specific treatment from Modules 4 onwards. But instead the solution described by Paul, to add a trailing ":" to the variable, is advised. You may initialize MANPATH to this value during the initialization of Modules, in the initrc configuration file (/etc/environment-modules/initrc): setenv MANPATH : Best regards, Xavier Le mar. 28 mai 2024 à 19:12, Paul Markfort <pau...@gm...> a écrit : > > Hopefully, this will help (both in solving the problem, and as a temporary fix). > > % module --version > Modules Release 5.4.0 (2024-02-20) > > % echo $MANPATH > :man::/stage/site/modules/default/man > > % module append-path MANPATH /tmp > > % echo $MANPATH > :man::/stage/site/modules/default/man:/tmp > > > I have (since before I started using 3.2) been pre-setting MANPATH like this (note my modules install is on an nfs share). > > The trick is the blank entry ":.. or "..::..." which causes man to search the default locations (the :man: is just an artifact to keep the :: - it used to be a documented feature). > > > On 2024-05-27 8:36 AM, Laurent BESSON wrote: > > Hello, > > > > Recently, I found that a simple < man ls > was no more working in my tcsh unix environment. Which is a bit surprising ! A < man > command reporting < No manual entry for ls > is quite odd on a Unix system ! > > > > After a bit of investigation, I found that my MANPATH variable was defined to < /tool/platform/lsf/8.0/man > without any mention to < /usr/share/man > or other regular unix man page dir. Weird ! But it explains why < man ls > was not working ! > > > > When using 5.4.0 version of Modules, here what I see, starting from a fresh terminal : > > > > > > 1. Before any module load, MANPATH variable is unset > > 2. < man ls > is working fine > > 3. Loading a module that has a < append-path > on MANPATH > > 4. < man ls > is no more working > > 5. MANPATH value is < /tool/platform/lsf/8.0/man > > > > > But when using a very old version of Modules, precisely 3.2.10 (from 2012 !!!!), I see : > > > > > > 1. Before any module load, MANPATH variable is unset > > 2. < man ls > is working fine > > 3. Loading a module that has a < append-path > on MANPATH > > 4. < man ls > is still working fine > > 5. MANPATH value is < > > /tool/platform/lsf/8.0/man:/usr/share/man:/usr/local/share/man > > > > > So, from my point of view, there is a regression on behavior of > > Modules when switching from 3.2 to 5.4 > > > > Could I have your opinions on this topic ? Is it a bug or a feature ? > > > > Best regards, > > Laurent. _______________________________________________ Modules-interest mailing list Mod...@li... https://lists.sourceforge.net/lists/listinfo/modules-interest |
|
From: Xavier D. <xav...@gm...> - 2024-05-29 04:29:53
|
Hello Laurent, There were a specific treatment for MANPATH on Modules 3.2 that initialized it to a value defined at compilation when changing this path. There is no more such specific treatment from Modules 4 onwards. But instead the solution described by Paul, to add a trailing ":" to the variable, is advised. You may initialize MANPATH to this value during the initialization of Modules, in the initrc configuration file (/etc/environment-modules/initrc): setenv MANPATH : Best regards, Xavier Le mar. 28 mai 2024 à 19:12, Paul Markfort <pau...@gm...> a écrit : > > Hopefully, this will help (both in solving the problem, and as a temporary fix). > > % module --version > Modules Release 5.4.0 (2024-02-20) > > % echo $MANPATH > :man::/stage/site/modules/default/man > > % module append-path MANPATH /tmp > > % echo $MANPATH > :man::/stage/site/modules/default/man:/tmp > > > I have (since before I started using 3.2) been pre-setting MANPATH like this (note my modules install is on an nfs share). > > The trick is the blank entry ":.. or "..::..." which causes man to search the default locations (the :man: is just an artifact to keep the :: - it used to be a documented feature). > > > On 2024-05-27 8:36 AM, Laurent BESSON wrote: > > Hello, > > > > Recently, I found that a simple < man ls > was no more working in my tcsh unix environment. Which is a bit surprising ! A < man > command reporting < No manual entry for ls > is quite odd on a Unix system ! > > > > After a bit of investigation, I found that my MANPATH variable was defined to < /tool/platform/lsf/8.0/man > without any mention to < /usr/share/man > or other regular unix man page dir. Weird ! But it explains why < man ls > was not working ! > > > > When using 5.4.0 version of Modules, here what I see, starting from a fresh terminal : > > > > > > 1. Before any module load, MANPATH variable is unset > > 2. < man ls > is working fine > > 3. Loading a module that has a < append-path > on MANPATH > > 4. < man ls > is no more working > > 5. MANPATH value is < /tool/platform/lsf/8.0/man > > > > > But when using a very old version of Modules, precisely 3.2.10 (from 2012 !!!!), I see : > > > > > > 1. Before any module load, MANPATH variable is unset > > 2. < man ls > is working fine > > 3. Loading a module that has a < append-path > on MANPATH > > 4. < man ls > is still working fine > > 5. MANPATH value is < /tool/platform/lsf/8.0/man:/usr/share/man:/usr/local/share/man > > > > > So, from my point of view, there is a regression on behavior of Modules when switching from 3.2 to 5.4 > > > > Could I have your opinions on this topic ? Is it a bug or a feature ? > > > > Best regards, > > Laurent. |
|
From: Paul M. <pau...@gm...> - 2024-05-28 17:12:01
|
Hopefully, this will help (both in solving the problem, and as a temporary fix). % module --version Modules Release 5.4.0 (2024-02-20) % echo $MANPATH :man::/stage/site/modules/default/man % module append-path MANPATH /tmp % echo $MANPATH :man::/stage/site/modules/default/man:/tmp I have (since before I started using 3.2) been pre-setting MANPATH like this (note my modules install is on an nfs share). The trick is the blank entry ":.. or "..::..." which causes man to search the default locations (the :man: is just an artifact to keep the :: - it used to be a documented feature). On 2024-05-27 8:36 AM, Laurent BESSON wrote: > Hello, > > Recently, I found that a simple < man ls > was no more working in my tcsh unix environment. Which is a bit surprising ! A < man > command reporting < No manual entry for ls > is quite odd on a Unix system ! > > After a bit of investigation, I found that my MANPATH variable was defined to < /tool/platform/lsf/8.0/man > without any mention to < /usr/share/man > or other regular unix man page dir. Weird ! But it explains why < man ls > was not working ! > > When using 5.4.0 version of Modules, here what I see, starting from a fresh terminal : > > > 1. Before any module load, MANPATH variable is unset > 2. < man ls > is working fine > 3. Loading a module that has a < append-path > on MANPATH > 4. < man ls > is no more working > 5. MANPATH value is < /tool/platform/lsf/8.0/man > > > But when using a very old version of Modules, precisely 3.2.10 (from 2012 !!!!), I see : > > > 1. Before any module load, MANPATH variable is unset > 2. < man ls > is working fine > 3. Loading a module that has a < append-path > on MANPATH > 4. < man ls > is still working fine > 5. MANPATH value is < /tool/platform/lsf/8.0/man:/usr/share/man:/usr/local/share/man > > > So, from my point of view, there is a regression on behavior of Modules when switching from 3.2 to 5.4 > > Could I have your opinions on this topic ? Is it a bug or a feature ? > > Best regards, > Laurent. > > > > _______________________________________________ > 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/ -------------------------------------------------------- |
|
From: Laurent B. <lau...@ea...> - 2024-05-28 16:28:56
|
Hello, Recently, I found that a simple < man ls > was no more working in my tcsh unix environment. Which is a bit surprising ! A < man > command reporting < No manual entry for ls > is quite odd on a Unix system ! After a bit of investigation, I found that my MANPATH variable was defined to < /tool/platform/lsf/8.0/man > without any mention to < /usr/share/man > or other regular unix man page dir. Weird ! But it explains why < man ls > was not working ! When using 5.4.0 version of Modules, here what I see, starting from a fresh terminal : 1. Before any module load, MANPATH variable is unset 2. < man ls > is working fine 3. Loading a module that has a < append-path > on MANPATH 4. < man ls > is no more working 5. MANPATH value is < /tool/platform/lsf/8.0/man > But when using a very old version of Modules, precisely 3.2.10 (from 2012 !!!!), I see : 1. Before any module load, MANPATH variable is unset 2. < man ls > is working fine 3. Loading a module that has a < append-path > on MANPATH 4. < man ls > is still working fine 5. MANPATH value is < /tool/platform/lsf/8.0/man:/usr/share/man:/usr/local/share/man > So, from my point of view, there is a regression on behavior of Modules when switching from 3.2 to 5.4 Could I have your opinions on this topic ? Is it a bug or a feature ? Best regards, Laurent. |
|
From: Paul M. <pau...@gm...> - 2024-04-26 14:19:19
|
Just some feedback. Hopefully this will help others make the decision to upgrade. Upgraded a Network install (that serves over 100 machines of varying versions of Linux, and even FreeBSD) about a month ago from 5.3.1 to 5.4.0 Works just fine - no complaints. I am making use of the ability to source some modules - nice you don't have to specify the full path to them (For environment initialization, and to add aliases on every interactive shell startup). Note - I modified the: /stage/site/modules/5.4.0/libexec/modulecmd.tcl TCL script (this is a network location) so it allows module source within a module (and so it doesn't export the functions it creates). I have one module that is sourced on every shell startup, that adds the aliases, and checks if another module (os-id) has been loaded (if it hasn't, it loads it - then sources additional modules to initialize the user's environment). Notes: 1. I also moved this binary addon: /stage/site/modules/5.4.0/NOT_USED/lib/libtclenvmodules.so from its normal location (as you can tell) as some of our installations are not binary compatible with the machine used to install the modules (I want the network install to be generic - we have a few older Linux machines, and a couple running FreeBSD). Nice that it doesn't complain that it isn't there (maybe a method to build/install just that dynamic library locally would be useful for some). 2. The old Linux machines include some Lab machines running openSUSE Leap 42.1 (which can't be upgraded as they are using specialized USB hardware that isn't supported on anything newer). I think I could use this single module install, on anything with a new enough tcl install. On 2024-02-20 7:28 AM, Xavier Delaruelle wrote: > Hello All, > > Modules 5.4 is here! As always, new version means many new features: > Enhancing extra specifiers, Purging sticky modules, Specific > modulepath labels, Unique module name loaded, Cache sourced files, > Abort on error, Improve error reporting, New options for source-sh > modulefile command. > > Details on the major changes included in this new release are provided > in the MIGRATING document. The list of all changes made in this new > version are described in the NEWS document. > > http://modules.readthedocs.io/en/stable/MIGRATING.html > http://modules.readthedocs.io/en/stable/NEWS.html > > The tarball of this new version can be downloaded at: > > http://downloads.sourceforge.net/modules/modules-5.4.0.tar.gz > > The zipball to install this new version on Windows platform can be > downloaded at: > > http://downloads.sourceforge.net/modules/modules-5.4.0-win.zip > > If you encounter any issue, please let us know by creating a ticket on > the project bug tracker at: > > https://github.com/cea-hpc/modules/issues > > Many thanks to Laurent Chardon and Jérémy Déchard for their > contribution to this release. Many thanks also all of you who improve > Modules by reporting bugs or sharing new ideas. > > Best regards, > Xavier > > > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > -- -------------------------------------------------------- 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/ -------------------------------------------------------- |
|
From: Adrien C. - G. E. <adr...@eo...> - 2024-04-26 08:43:46
|
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
|
|
From: Adrien C. - G. E. <adr...@eo...> - 2024-04-20 07:48:22
|
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
|
|
From: Xavier D. <xav...@gm...> - 2024-04-20 05:53:42
|
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
|
