Better Modules Naming Scheme #13775
Replies: 9 comments
-
Just yesterday I was about opening an issue about a module names conflict I have with my package set. I have the same package installed with different variants. e.g. wyna7zj hpx@1.3.0 build_type=Debug ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=jemalloc max_cpu_count=128 ~networking~tools
zya72yn hpx@1.3.0 build_type=Debug ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=tcmalloc max_cpu_count=128 ~networking~tools
mn4ukz7 hpx@1.3.0 build_type=Release ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=jemalloc max_cpu_count=128 ~networking~tools
ha562lm hpx@1.3.0 build_type=Release ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=tcmalloc max_cpu_count=128 ~networking~tools I cannot even create the modules because this result in a name conflicts: spack module tcl refresh hpx
==> You are about to regenerate tcl module files for:
-- cray-cnl7-broadwell / gcc@8.3.0 ------------------------------
wyna7zj hpx@1.3.0 zya72yn hpx@1.3.0 mn4ukz7 hpx@1.3.0 ha562lm hpx@1.3.0
==> Do you want to proceed? [y/n] y
==> Error: Name clashes detected in module files:
file: /apps/daint/SSL/software/spack-current/share/spack/modules/cray-cnl7-broadwell/hpx/1.3.0-gcc-8.3.0-cray-cnl7-broadwell-mpi-python3
spec: hpx@1.3.0%gcc@8.3.0 build_type=Debug ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=jemalloc max_cpu_count=128 ~networking~tools arch=cray-cnl7-broadwell
spec: hpx@1.3.0%gcc@8.3.0 build_type=Debug ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=tcmalloc max_cpu_count=128 ~networking~tools arch=cray-cnl7-broadwell
file: /apps/daint/SSL/software/spack-current/share/spack/modules/cray-cnl7-broadwell/hpx/1.3.0-gcc-8.3.0-cray-cnl7-broadwell-release-mpi-python3
spec: hpx@1.3.0%gcc@8.3.0 build_type=Release ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=jemalloc max_cpu_count=128 ~networking~tools arch=cray-cnl7-broadwell
spec: hpx@1.3.0%gcc@8.3.0 build_type=Release ~cuda cuda_arch=none cxxstd=14 instrumentation=none malloc=tcmalloc max_cpu_count=128 ~networking~tools arch=cray-cnl7-broadwell
==> Error: Operation aborted I think this may be a good support for the @adamjstewart's feature request. |
Beta Was this translation helpful? Give feedback.
-
@adamjstewart This is not a big change, but what is it giving more than: modules:
tcl:
hash_length: 0 plus the possibility to add suffixes? If you are in a situation like: -- cray-cnl7-broadwell / gcc@8.3.0 ------------------------------
wyna7zj hpx@1.3.0 zya72yn hpx@1.3.0 mn4ukz7 hpx@1.3.0 ha562lm hpx@1.3.0 would: $ spack load hpx@1.3.0 load anything deterministically in your case? @albestro How do you envision loading each one of the four |
Beta Was this translation helpful? Give feedback.
-
I never tried, but I would make the spec more detailed. spack load hpx@1.3.0 build_type=Release malloc=jemalloc Would it be possible? |
Beta Was this translation helpful? Give feedback.
-
@albestro If you do it like that (i.e. you use |
Beta Was this translation helpful? Give feedback.
-
Yes, true. The problem is that at the moment I cannot generate modules for these packages at all. But, I thought that what @adamjstewart was suggesting in the end of his first comment
could solve my problem. Isn't it? |
Beta Was this translation helpful? Give feedback.
-
@albestro My point is that you can probably solve your issue right now by changing your configuration. Can you share the output of: $ spack config blame modules ? |
Beta Was this translation helpful? Give feedback.
-
You pointed me in the right direction, I didn't know that I was able to customize the module name
Thank you for helping me! |
Beta Was this translation helpful? Give feedback.
-
@alalazo Yes, this is specific to |
Beta Was this translation helpful? Give feedback.
-
We had done this local modification in our deployed software installation on our main cluster in production, @adamjstewart. I don't think it served as that well in the end, since we conditionally appended stuff like So, I would keep the |
Beta Was this translation helpful? Give feedback.
-
Currently, you can specify a module naming scheme like:
I would like the ability to change this to:
Where
{hash}
is the hash and7
is the hash length.Rationale
When I load a module, I have several options. If I don't care which version, I can say:
$ module load zlib
If I do care about the version, I would like to be able to do:
$ module load zlib/1.2.8
Currently this doesn't work, because Spack automatically appends the hash after a dash instead of a slash.
Description
Currently, I've been using the following workaround locally:
By making this a configuration option, users can have more flexibility as to how module files are named.
@becker33 @alalazo
Beta Was this translation helpful? Give feedback.
All reactions