Menu
▾
▴
modules-interest — Discussion forum for modules usage.
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
(5) |
Sep
(8) |
Oct
(3) |
Nov
|
Dec
|
|
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
|
|
From: Adrien C. - G. E. <adr...@eo...> - 2024-04-19 10:57:23
|
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 |
|
From: Xavier D. <xav...@gm...> - 2024-03-27 08:00:37
|
Hello All, We are pleased to announce the first release of `MoGui`, the Graphical User Interface for Modules. This simple application helps users to manage their module environment in a graphical desktop environment. https://github.com/cea-hpc/mogui This first release (0.2) is available from PyPi (https://pypi.org/project/modules-gui/). This app is still in beta stage. Bug report and contributions are highly welcomed Regards, Xavier |
|
From: Xavier D. <xav...@gm...> - 2024-02-22 10:23:22
|
Hello Laurent, I agree with you, it may be preferable to keep completion for "ml" simple. Maybe add completion for long option when "--" is entered. Best regards, Xavier Le mer. 21 févr. 2024 à 13:04, Laurent BESSON <lau...@ea...> a écrit : > > Hello, > > I have tried to add all possible completion from "module" command to "ml" command but, at the end, I found it confusing: > > Trying to hit "tab" after: > >>>> ml - > > will list all already loaded modules but also all possible options of module command (like "--version"). So the display is a bit messy with a mix of loaded modules and options. I think we are losing the simplicity of the new "ml" command whose first intention is to list/load/unload. > > Same when trying to complete "ml " with either the available modules and all the commands of "module". > > However, as suggested, I'll fire a new request under GitHub with essential completion for ml > > BR, > Laurent. > > > -----Message d'origine----- > De : Xavier Delaruelle <xav...@gm...> > Envoyé : mardi 20 février 2024 18:53 > À : Environment Modules usage and discussion. <mod...@li...> > Objet : Re: [Modules] Add completetion for "ml" command > > Hello Laurent, > > It would be very interesting to have ml completion added for tcsh shell. Would you like to contribute and create a pull request for that? > > init/tcsh_completion.in file should be updated with a "complete ml" > definition. From my understanding, this definition should equal the content of "complete module" + definition you propose. > > Best regards, > Xavier > > Le mar. 20 févr. 2024 à 16:57, Laurent BESSON <lau...@ea...> a écrit : > > > > Hello, > > > > > > > > Would it be possible to add shell completion for the almost-new « ml » command. > > > > On my side, using tcsh as my loggin shell, I have defined the following : > > > > > > > > complete ml 'c/-/`_module_loaded`/' \ > > > > 'p/1/`_module_not_yet_loaded; echo "-"`/' > > > > > > > > Which is working quite well. > > > > > > > > Best regards, > > > > Laurent. |
|
From: Xavier D. <xav...@gm...> - 2024-02-21 19:10:29
|
Hello, For those who prefer Mastodon over X (Twitter), I have created the @Env...@ma...cial account. I will relay news of the project through this profile (in addition to this mailing-list and Twitter). Come follow me at https://mast.hpc.social/@EnvModules Regards, Xavier |
|
From: Laurent B. <lau...@ea...> - 2024-02-21 12:02:55
|
Hello, I have tried to add all possible completion from "module" command to "ml" command but, at the end, I found it confusing: Trying to hit "tab" after: >>>> ml - will list all already loaded modules but also all possible options of module command (like "--version"). So the display is a bit messy with a mix of loaded modules and options. I think we are losing the simplicity of the new "ml" command whose first intention is to list/load/unload. Same when trying to complete "ml " with either the available modules and all the commands of "module". However, as suggested, I'll fire a new request under GitHub with essential completion for ml BR, Laurent. -----Message d'origine----- De : Xavier Delaruelle <xav...@gm...> Envoyé : mardi 20 février 2024 18:53 À : Environment Modules usage and discussion. <mod...@li...> Objet : Re: [Modules] Add completetion for "ml" command Hello Laurent, It would be very interesting to have ml completion added for tcsh shell. Would you like to contribute and create a pull request for that? init/tcsh_completion.in file should be updated with a "complete ml" definition. From my understanding, this definition should equal the content of "complete module" + definition you propose. Best regards, Xavier Le mar. 20 févr. 2024 à 16:57, Laurent BESSON <lau...@ea...> a écrit : > > Hello, > > > > Would it be possible to add shell completion for the almost-new « ml » command. > > On my side, using tcsh as my loggin shell, I have defined the following : > > > > complete ml 'c/-/`_module_loaded`/' \ > > 'p/1/`_module_not_yet_loaded; echo "-"`/' > > > > Which is working quite well. > > > > Best regards, > > Laurent. > > _______________________________________________ > 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: Harlan S. <ha...@pf...> - 2024-02-21 05:27:20
|
On 2/20/2024 8:38 PM, Sternberg, Michael G. via Modules-interest wrote:
> You can certainly get by with a single perl binary by putting the
> specific version of openssl right under its nose, though a script wrapper:
>
> ----------------------------
> #!/bin/sh
> LD_LIBRARY_PATH=/path/to/openssl/lib${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"} \
> exec /path/to/bin/perl \
> ${1+"$@"}
> ----------------------------
>
> Place this script "earlier" in your PATH than your perl binary.
>
> If you happen to control that perl binary yourself (as opposed to e.g.
> your system's package manager), you could also move it to, say,
> ../libexec/ and place the script in its stead. In that case, you could
> write "… exec $(dirname $0)/../libexec/perl …" to locate it.
Thanks!
And:
- I'd greatly prefer to avoid LD_LIBRARY_PATH, as relying on this has
always resulted in intricate debugging problems and drama. It also
requires education and significant attention on the part of the
sysadmin/releng/build teams.
- Is there a non-clunky solution to the problem of needing to compile
N instances of perl for each of the N versions of openssl that are
available?
My first point above is still a major concern for me.
The 2nd point is independent of the first point. Doing N instances of
perl+openssl may be what has to happen. And I'm wondering what other
toolchains will need to have their own collections:
- perl-$PERLVER--noopenssl
- perl-$PERLVER--openssl-$OPENSSLVER
H
--
> With best regards,
> --
> Michael Sternberg, Ph.D.
> Principal Scientific Computing Administrator
> Center for Nanoscale Materials
> Argonne National Laboratory
>
>
>
>> On Feb 20, 2024, at 20:56, Harlan Stenn <ha...@pf...> wrote:…There
>> are some CPAN modules that work with, for example, OpenSSL. These
>> CPAN modules need the right/appropriate OpenSSL libraries at runtime.
>>
>> CPAN modules apparently Do Not Want to be statically linked. I think
>> the best solution is to find a way to install CPAN modules that have
>> been statically linked to there appropriate (at build time) libraries.
>>
>> I really don't want to use LD_LIBRARY_PATH to solve this problem,
>> because in an environment where modules is in use, one might be using
>> several different sets of tools, and the openssl being used by perl and
>> the perl modules might be different from the version of openssl that is
>> used by some other set of utilities that are needed for the current
>> overall operating environment.
>>
>> I am trying Really Hard to not have to build a separate version of perl
>> (and the CPAN modules) for each version of OpenSSL.
>>
>> I figure there are more "flavors" involved than just OpenSSL, so the
>> problem above will only get worse if I have to build an entire toolchain
>> suite for each "flavor".
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|
|
From: Sternberg, M. G. <ste...@an...> - 2024-02-21 04:52:54
|
You can certainly get by with a single perl binary by putting the specific version of openssl right under its nose, though a script wrapper:
----------------------------
#!/bin/sh
LD_LIBRARY_PATH=/path/to/openssl/lib${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"} \
exec /path/to/bin/perl \
${1+"$@"}
----------------------------
Place this script "earlier" in your PATH than your perl binary.
If you happen to control that perl binary yourself (as opposed to e.g. your system's package manager), you could also move it to, say, ../libexec/ and place the script in its stead. In that case, you could write "… exec $(dirname $0)/../libexec/perl …" to locate it.
With best regards,
--
Michael Sternberg, Ph.D.
Principal Scientific Computing Administrator
Center for Nanoscale Materials
Argonne National Laboratory
On Feb 20, 2024, at 20:56, Harlan Stenn <ha...@pf...> wrote:…There are some CPAN modules that work with, for example, OpenSSL. These
CPAN modules need the right/appropriate OpenSSL libraries at runtime.
CPAN modules apparently Do Not Want to be statically linked. I think
the best solution is to find a way to install CPAN modules that have
been statically linked to there appropriate (at build time) libraries.
I really don't want to use LD_LIBRARY_PATH to solve this problem,
because in an environment where modules is in use, one might be using
several different sets of tools, and the openssl being used by perl and
the perl modules might be different from the version of openssl that is
used by some other set of utilities that are needed for the current
overall operating environment.
I am trying Really Hard to not have to build a separate version of perl
(and the CPAN modules) for each version of OpenSSL.
I figure there are more "flavors" involved than just OpenSSL, so the
problem above will only get worse if I have to build an entire toolchain
suite for each "flavor".
|
|
From: Harlan S. <ha...@pf...> - 2024-02-21 02:55:04
|
I haven't had to deal with this in a long time, and I'm hoping somebody here can save me a lot of time to get a working answer. There are some CPAN modules that work with, for example, OpenSSL. These CPAN modules need the right/appropriate OpenSSL libraries at runtime. CPAN modules apparently Do Not Want to be statically linked. I think the best solution is to find a way to install CPAN modules that have been statically linked to there appropriate (at build time) libraries. I really don't want to use LD_LIBRARY_PATH to solve this problem, because in an environment where modules is in use, one might be using several different sets of tools, and the openssl being used by perl and the perl modules might be different from the version of openssl that is used by some other set of utilities that are needed for the current overall operating environment. I am trying Really Hard to not have to build a separate version of perl (and the CPAN modules) for each version of OpenSSL. I figure there are more "flavors" involved than just OpenSSL, so the problem above will only get worse if I have to build an entire toolchain suite for each "flavor". I'd bet that some folks here have had to deal with this situation and might have answers for me. Thanks... H |
|
From: Xavier D. <xav...@gm...> - 2024-02-20 17:53:50
|
Hello Laurent, It would be very interesting to have ml completion added for tcsh shell. Would you like to contribute and create a pull request for that? init/tcsh_completion.in file should be updated with a "complete ml" definition. From my understanding, this definition should equal the content of "complete module" + definition you propose. Best regards, Xavier Le mar. 20 févr. 2024 à 16:57, Laurent BESSON <lau...@ea...> a écrit : > > Hello, > > > > Would it be possible to add shell completion for the almost-new « ml » command. > > On my side, using tcsh as my loggin shell, I have defined the following : > > > > complete ml 'c/-/`_module_loaded`/' \ > > 'p/1/`_module_not_yet_loaded; echo "-"`/' > > > > Which is working quite well. > > > > Best regards, > > Laurent. > > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest |
|
From: Laurent B. <lau...@ea...> - 2024-02-20 15:56:23
|
Hello,
Would it be possible to add shell completion for the almost-new < ml > command.
On my side, using tcsh as my loggin shell, I have defined the following :
complete ml 'c/-/`_module_loaded`/' \
'p/1/`_module_not_yet_loaded; echo "-"`/'
Which is working quite well.
Best regards,
Laurent.
|
40 messages has been excluded from this view by a project administrator.
