zhangyiss/spack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
e5a2c9aee3
spack/etc/spack/defaults/modules.yaml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

56 lines
1.5 KiB
YAML
Raw Normal View History

module files configuration : added default configuration
2016-03-24 17:04:02 +08:00
# -------------------------------------------------------------------------
Add "default" configuration scope. - Default scope is versioned with spack and can be overridden by site or user config. - Default scope provides sensible default concretization preferences for all of Spack. - per-platform concretization scope can be added later (to force a particular MPI on, e.g., Cray systems)
2016-07-20 08:10:17 +08:00
# This is the default configuration for Spack's module file generation.
module files configuration : added default configuration
2016-03-24 17:04:02 +08:00
#
Add "default" configuration scope. - Default scope is versioned with spack and can be overridden by site or user config. - Default scope provides sensible default concretization preferences for all of Spack. - per-platform concretization scope can be added later (to force a particular MPI on, e.g., Cray systems)
2016-07-20 08:10:17 +08:00
# Settings here are versioned with Spack and are intended to provide
# sensible defaults out of the box. Spack maintainers should edit this
# file to keep it current.
#
# Users can override these settings by editing the following files.
#
# Per-spack-instance settings (overrides defaults):
# $SPACK_ROOT/etc/spack/modules.yaml
#
# Per-user settings (overrides default and site settings):
# ~/.spack/modules.yaml
module files configuration : added default configuration
2016-03-24 17:04:02 +08:00
# -------------------------------------------------------------------------
modules:
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
# This maps paths in the package install prefix to environment variables
# they should be added to. For example, <prefix>/bin should be in PATH.
Simplify /etc/spack/modules.yaml formatting.
2016-05-12 00:05:24 +08:00
prefix_inspections:
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./bin:
Simplify /etc/spack/modules.yaml formatting.
2016-05-12 00:05:24 +08:00
- PATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./man:
Simplify /etc/spack/modules.yaml formatting.
2016-05-12 00:05:24 +08:00
- MANPATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./share/man:
Add share/man to prefix inspections. The share/man path should be in prefix_inspections for MANPATH as share/man is a common location for manual pages.
2016-07-12 02:35:22 +08:00
- MANPATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./share/aclocal:
add ACLOCAL_PATH updates for packages that register m4 macros (#2518)
2016-12-08 05:53:57 +08:00
- ACLOCAL_PATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./lib/pkgconfig:
modules.yaml: use the right envvar for pkg-config Fixes #1072.
2016-06-20 23:10:13 +08:00
- PKG_CONFIG_PATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./lib64/pkgconfig:
modules.yaml: use the right envvar for pkg-config Fixes #1072.
2016-06-20 23:10:13 +08:00
- PKG_CONFIG_PATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./share/pkgconfig:
Consistently support pkg-config files in share subdirectory (#12838) While the build environment already takes share/pkgconfig into account, the generated module files etc. only consider lib/pkgconfig and lib64/pkgconfig.
2019-10-06 10:03:35 +08:00
- PKG_CONFIG_PATH
Relative paths in default prefix_inspections start with ./ (#31867)
2022-08-24 03:54:12 +08:00
./:
Simplify /etc/spack/modules.yaml formatting.
2016-05-12 00:05:24 +08:00
- CMAKE_PREFIX_PATH
Modulefiles generated with a template engine (#3183) * Module files now are generated using a template engine refers #2902 #3173 jinja2 has been hooked into Spack. The python module `modules.py` has been splitted into several modules under the python package `spack/modules`. Unit tests stressing module file generation have been refactored accordingly. The module file generator for Lmod has been extended to multi-providers and deeper hierarchies. * Improved the support for templates in module files. Added an entry in `config.yaml` (`template_dirs`) to list all the directories where Spack could find templates for `jinja2`. Module file generators have a simple override mechanism to override template selection ('modules.yaml' beats 'package.py' beats 'default'). * Added jinja2 and MarkupSafe to vendored packages. * Spec.concretize() sets mutual spec-package references The correct place to set the mutual references between spec and package objects at the end of concretization. After a call to concretize we should now be ensured that spec is the same object as spec.package.spec. Code in `build_environment.py` that was performing the same operation has been turned into an assertion to be defensive on the new behavior. * Improved code and data layout for modules and related tests. Common fixtures related to module file generation have been extracted in `conftest.py`. All the mock configurations for module files have been extracted from python code and have been put into their own yaml file. Added a `context_property` decorator for the template engine, to make it easy to define dictionaries out of properties. The default for `verbose` in `modules.yaml` is now False instead of True. * Extendable module file contexts + short description from docstring The contexts that are used in conjunction with `jinja2` templates to generate module files can now be extended from package.py and modules.yaml. Module files generators now infer the short description from package.py docstring (and as you may expect it's the first paragraph) * 'module refresh' regenerates all modules by default `module refresh` without `--module-type` specified tries to regenerate all known module types. The same holds true for `module rm` Configure options used at build time are extracted and written into the module files where possible. * Fixed python3 compatibility, tests for Lmod and Tcl. Added test for exceptional paths of execution when generating Lmod module files. Fixed a few compatibility issues with python3. Fixed a bug in Tcl with naming_scheme and autoload + unit tests * Updated module file tutorial docs. Fixed a few typos in docstrings. The reference section for module files has been reorganized. The idea is to have only three topics at the highest level: - shell support + spack load/unload use/unuse - module file generation (a.k.a. APIs + modules.yaml) - module file maintenance (spack module refresh/rm) Module file generation will cover the entries in modules.yaml Also: - Licenses have been updated to include NOTICE and extended to 2017 - docstrings have been reformatted according to Google style * Removed redundant arguments to RPackage and WafPackage. All the callbacks in `RPackage` and `WafPackage` that are not build phases have been modified not to accept a `spec` and a `prefix` argument. This permits to leverage the common `configure_args` signature to insert by default the configuration arguments into the generated module files. I think it's preferable to handling those packages differently than `AutotoolsPackage`. Besides only one package seems to override one of these methods. * Fixed broken indentation + improved resiliency of refresh Fixed broken indentation in `spack module refresh` (probably a rebase gone silently wrong?). Filter the writers for blacklisted specs before searching for name clashes. An error with a single writer will not stop regeneration, but instead will print a warning and continue the command.
2017-09-20 03:34:20 +08:00
Separable module configuration -- without the bugs this time (#23703) Currently, module configurations are inconsistent because modulefiles are generated with the configs for the active environment, but are shared among all environments (and spack outside any environment). This PR fixes that by allowing Spack environments (or other spack config scopes) to define additional sets of modules to generate. Each set of modules can enable either lmod or tcl modules, and contains all of the previously available module configuration. The user defines the name of each module set -- the set configured in Spack by default is named "default", and is the one returned by module manipulation commands in the absence of user intervention. As part of this change, the module roots configuration moved from the config section to inside each module configuration. Additionally, it adds a feature that the modulefiles for an environment can be configured to be relative to an environment view rather than the underlying prefix. This will not be enabled by default, as it should only be enabled within an environment and for non-default views constructed with separate projections per-spec.
2021-05-29 05:12:05 +08:00
# These are configurations for the module set named "default"
default:
# Where to install modules
Deprecate top-level module config (#28659) * Ignore top-level module config; add auto-update In Spack 0.17 we got module sets (modules:[name]:[prop]), and for backwards compat modules:[prop] was short for modules:default:[prop]. But this makes it awkward to define default config for the "default" module set. Since 0.17 is branched off, we can now deprecate top-level module config (that is, just ignore it with a warning). This PR does that, and it implements `spack config update modules` to make upgrading easy (we should have added that to 0.17 already...) It also removes references to `dotkit` stuff which was already deprecated in 0.13 and could have been removed in 0.14. Prefix inspections are the only exception, since the top-level prefix inspections used for `spack load` and `spack env activate`.
2022-04-09 03:00:35 +08:00
roots:
tcl: $spack/share/spack/modules
lmod: $spack/share/spack/lmod
Disable module file generation by default (#37258) * Disable module generation by default (#35564) a) It's used by site administrators, so it's niche b) If it's used by site administrators, they likely need to modify the config anyhow, so the default config only serves as an example to get started c) it's too arbitrary to enable tcl, but disable lmod * Remove leftover from old module file schema * Warn if module file config is detected and generation is disabled --------- Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
2023-05-02 16:28:27 +08:00
# What type of modules to use ("tcl" and/or "lmod")
enable: []
Separable module configuration -- without the bugs this time (#23703) Currently, module configurations are inconsistent because modulefiles are generated with the configs for the active environment, but are shared among all environments (and spack outside any environment). This PR fixes that by allowing Spack environments (or other spack config scopes) to define additional sets of modules to generate. Each set of modules can enable either lmod or tcl modules, and contains all of the previously available module configuration. The user defines the name of each module set -- the set configured in Spack by default is named "default", and is the one returned by module manipulation commands in the absence of user intervention. As part of this change, the module roots configuration moved from the config section to inside each module configuration. Additionally, it adds a feature that the modulefiles for an environment can be configured to be relative to an environment view rather than the underlying prefix. This will not be enabled by default, as it should only be enabled within an environment and for non-default views constructed with separate projections per-spec.
2021-05-29 05:12:05 +08:00
Switch lmod default all:autoload from none to direct (#28357) * Switch lmod module all autoload default from none to direct * Fix the docs
2022-01-19 01:06:41 +08:00
tcl:
all:
modules tcl: switch default all:autoload from none to direct (#36269) Since environment-modules has support for autoloading since 4.2, and Spack-builds of it enable it by default, use the same autoload default for tcl as lmod.
2023-03-23 14:49:17 +08:00
autoload: direct
Switch lmod default all:autoload from none to direct (#28357) * Switch lmod module all autoload default from none to direct * Fix the docs
2022-01-19 01:06:41 +08:00
Separable module configuration -- without the bugs this time (#23703) Currently, module configurations are inconsistent because modulefiles are generated with the configs for the active environment, but are shared among all environments (and spack outside any environment). This PR fixes that by allowing Spack environments (or other spack config scopes) to define additional sets of modules to generate. Each set of modules can enable either lmod or tcl modules, and contains all of the previously available module configuration. The user defines the name of each module set -- the set configured in Spack by default is named "default", and is the one returned by module manipulation commands in the absence of user intervention. As part of this change, the module roots configuration moved from the config section to inside each module configuration. Additionally, it adds a feature that the modulefiles for an environment can be configured to be relative to an environment view rather than the underlying prefix. This will not be enabled by default, as it should only be enabled within an environment and for non-default views constructed with separate projections per-spec.
2021-05-29 05:12:05 +08:00
# Default configurations if lmod is enabled
lmod:
Switch lmod default all:autoload from none to direct (#28357) * Switch lmod module all autoload default from none to direct * Fix the docs
2022-01-19 01:06:41 +08:00
all:
autoload: direct
Separable module configuration -- without the bugs this time (#23703) Currently, module configurations are inconsistent because modulefiles are generated with the configs for the active environment, but are shared among all environments (and spack outside any environment). This PR fixes that by allowing Spack environments (or other spack config scopes) to define additional sets of modules to generate. Each set of modules can enable either lmod or tcl modules, and contains all of the previously available module configuration. The user defines the name of each module set -- the set configured in Spack by default is named "default", and is the one returned by module manipulation commands in the absence of user intervention. As part of this change, the module roots configuration moved from the config section to inside each module configuration. Additionally, it adds a feature that the modulefiles for an environment can be configured to be relative to an environment view rather than the underlying prefix. This will not be enabled by default, as it should only be enabled within an environment and for non-default views constructed with separate projections per-spec.
2021-05-29 05:12:05 +08:00
hierarchy:
- mpi
Reference in New Issue Copy Permalink