Pmodules issueshttps://gitlab.psi.ch/groups/Pmodules/-/issues2022-11-28T14:49:12+01:00https://gitlab.psi.ch/Pmodules/buildblocks/-/issues/252ncurses module2022-11-28T14:49:12+01:00gsellncurses modulegsellgsellhttps://gitlab.psi.ch/Pmodules/buildblocks/-/issues/245nvim: new module2022-10-27T17:59:33+02:00gsellnvim: new moduleSee: https://neovim.ioSee: https://neovim.iogsellgsellhttps://gitlab.psi.ch/Pmodules/src/-/issues/170Bash 5 modbuild requirement2023-05-12T10:38:22+02:00bliven_sBash 5 modbuild requirementI noticed that building in 1.1.9 requires bash 5.x. Is this a hard requirement? Should bash/5.x be added as a dependency for the Pmodules module so that `module load Pmodules` gives a working build environment?I noticed that building in 1.1.9 requires bash 5.x. Is this a hard requirement? Should bash/5.x be added as a dependency for the Pmodules module so that `module load Pmodules` gives a working build environment?https://gitlab.psi.ch/Pmodules/src/-/issues/169Use semantic versioning2022-10-27T15:44:33+02:00bliven_sUse semantic versioningI suggest transitioning pmodules to use semantic versioning. The current use of release candidate prefixes on the stable line and 1.x.x for the development line is confusing. I suggest that the next stable version be 2.0.0 and from there...I suggest transitioning pmodules to use semantic versioning. The current use of release candidate prefixes on the stable line and 1.x.x for the development line is confusing. I suggest that the next stable version be 2.0.0 and from there releases follow standard MAJOR.MINOR.PATCH[-devX] nomenclature.
It might be good to change the git practices too so that the default branch (master) corresponds to the most recent development branch. This way the README and CHANGELOG displayed for the project include the most recent info.https://gitlab.psi.ch/Pmodules/buildblocks/-/issues/217mpich/3.3.2_merlin with gcc/11.22022-04-01T15:58:32+02:00gsellmpich/3.3.2_merlin with gcc/11.2# New module variant
* **Name:** mpich/3.3.2_merlin
* **Group:** Compiler
* **with:** gcc/11.2
* **System:** merlin
* **Overlay** base# New module variant
* **Name:** mpich/3.3.2_merlin
* **Group:** Compiler
* **with:** gcc/11.2
* **System:** merlin
* **Overlay** basegsellgsellhttps://gitlab.psi.ch/Pmodules/src/-/issues/155Dependency conflicts are not transitive2022-11-09T17:58:26+01:00bliven_sDependency conflicts are not transitiveIn order to specify module conflicts it's currently necessary to add the 'conflict' clause to the modulefiles of both packages. This can lead to bugs: today I noticed that anaconda is marked as conflicting with psi-python*, but not vice ...In order to specify module conflicts it's currently necessary to add the 'conflict' clause to the modulefiles of both packages. This can lead to bugs: today I noticed that anaconda is marked as conflicting with psi-python*, but not vice versa. This means that if anaconda is loaded before psi-python27 then no error is reported.
Is this something that pmodules should handle (by checking conflict lines of currently loaded packages during load operations), or is it just something to be aware of when writing module files?https://gitlab.psi.ch/Pmodules/src/-/issues/153Build problems with rc102021-12-08T18:04:14+01:00caubet_mBuild problems with rc10There's some issue when loading it from `/etc/profile.d/pmodules.sh`
```bash
(base) ❄ [caubet_m@merlin-l-001:/data/user/caubet_m/GIT/buildblocks/Compiler/openmpi]$ module -V
Pmodules 1.0.0rc10 using Tcl Environment Modules
Copyright GN...There's some issue when loading it from `/etc/profile.d/pmodules.sh`
```bash
(base) ❄ [caubet_m@merlin-l-001:/data/user/caubet_m/GIT/buildblocks/Compiler/openmpi]$ module -V
Pmodules 1.0.0rc10 using Tcl Environment Modules
Copyright GNU GPL v2
(base) ❄ [caubet_m@merlin-l-001:/data/user/caubet_m/GIT/buildblocks/Compiler/openmpi]$ ./build 4.1.1_slurm --system=merlin6
/usr/bin/env: modbuild: No such file or directory
(base) ❄ [caubet_m@merlin-l-001:/data/user/caubet_m/GIT/buildblocks/Compiler/openmpi]$ module load Pmodules/1.0.0rc10
(base) ❄ [caubet_m@merlin-l-001:/data/user/caubet_m/GIT/buildblocks/Compiler/openmpi]$ ./build 4.1.1_slurm --system=merlin6
openmpi/4.1.1_slurm: with gcc/10.2.0 cuda/11.3.0 b:ucx/1.12.0_slurm building ...
Loading module: gcc/10.2.0
Loading module: cuda/11.3.0
ucx/1.12.0_slurm: module does not exist, trying to build it...
ucx/1.12.0_slurm: no suitable variant found!
Aborting...
ucx/1.12.0_slurm: oops: build failed...
```https://gitlab.psi.ch/Pmodules/buildblocks/-/issues/159ray_py38 python env lacks tabulate2021-05-18T08:32:33+02:00feichtingerray_py38 python env lacks tabulateA. Adelmann wants to use `ray.tune` which requires `tabulate` support
```python
In [1]: from ray import tune
...
/opt/psi/Programming/anaconda/2019.07/conda/envs/ray_py38.yml/lib/python3.8/site-packages/ray/tune/progress_reporter.py in ...A. Adelmann wants to use `ray.tune` which requires `tabulate` support
```python
In [1]: from ray import tune
...
/opt/psi/Programming/anaconda/2019.07/conda/envs/ray_py38.yml/lib/python3.8/site-packages/ray/tune/progress_reporter.py in <module>
21 from tabulate import tabulate
22 except ImportError:
---> 23 raise ImportError("ray.tune in ray > 0.7.5 requires 'tabulate'. "
24 "Please re-run 'pip install ray[tune]' or "
25 "'pip install ray[rllib]'.")
ImportError: ray.tune in ray > 0.7.5 requires 'tabulate'. Please re-run 'pip install ray[tune]' or 'pip install ray[rllib]'.
```feichtingerfeichtingerhttps://gitlab.psi.ch/Pmodules/buildblocks/-/issues/70new conda environment ra-standard_py362020-06-10T11:06:33+02:00salanew conda environment ra-standard_py36New RA python environment based on the new concept, currently used and tested on test JupyterHub system jupytera01New RA python environment based on the new concept, currently used and tested on test JupyterHub system jupytera01salasalahttps://gitlab.psi.ch/Pmodules/src/-/issues/28group arguments for whatis2017-11-15T18:27:33+01:00gsellgroup arguments for whatisIt should be possible to pass groups to the whatis commands. Example
```sh
module whatis Tools
```
should print whatis information about all available modules in the group ToolsIt should be possible to pass groups to the whatis commands. Example
```sh
module whatis Tools
```
should print whatis information about all available modules in the group Toolsgsellgsellhttps://gitlab.psi.ch/Pmodules/src/-/issues/19Use cache for available modulefiles and relevant data to speedup loading2018-09-10T21:32:22+02:00gsellUse cache for available modulefiles and relevant data to speedup loadingLoading a module is pretty slow to the the required actions on the file-system. All relevant data to load a module should be kept in a cache.
* This cache must/should be updated manually after adding a new module.
* Using the cache is ...Loading a module is pretty slow to the the required actions on the file-system. All relevant data to load a module should be kept in a cache.
* This cache must/should be updated manually after adding a new module.
* Using the cache is optional:
* the cache is not used at all
* the cache is used, if a module is not found, fallback to 'traditional' behavior
* the cache is used, if a module is not found, print an errorgsellgsell