-
Notifications
You must be signed in to change notification settings - Fork 149
document support for creating module 'wrappers' for dependencies #453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| .. _wrapping_dependencies: | ||
|
|
||
| Wrapping dependencies | ||
| ===================== | ||
|
|
||
| Since EasyBuild v3.7.0 a special-purpose generic easyblock named ``ModuleRC`` is available, | ||
| which can be used to generate a (software-specific) ``.modulerc`` file | ||
| (as opposed to generating an actual module file). | ||
|
|
||
| .. note:: For compatibility with the different modules tools supported by EasyBuild (see :ref:`modules_tool`), | ||
| the ``.modulerc`` file is always generated in Tcl syntax (for now), regardless of the module syntax | ||
| that is used for module files. Only Lmod 7.8 or more recent supports ``.modulerc.lua`` files | ||
| in Lua syntax. | ||
|
|
||
| The ``ModuleRC`` easyblock supports including ``module-version`` in the generated ``.modulerc`` file, | ||
| which defines a so-called *"symbolic version"*. | ||
|
|
||
| This can be used to install a *"wrapper"* for a particular module, which can be useful in the context | ||
| of dependencies. For example, it can be used to avoid dependending on a specific version of | ||
|
||
| a particular software package by specifying the dependency only on the ``<major>.<minor>`` version instead | ||
| (i.e., without including the "subminor" version, which usually corresponds to a bugfix release). | ||
|
|
||
| One particular example where this is employed is for ``Java``. Since the ``2018b`` generation of | ||
| the :ref:`common_toolchains`, we use a wrapper for ``Java`` (e.g., ``Java/1.8``), rather than | ||
| depending on a specific version (e.g., ``Java/1.8.0_181``): | ||
|
|
||
| .. code:: | ||
|
|
||
| # specify dependency on Java/1.8 "wrapper", rather than a specific Java version | ||
| dependencies = [('Java', '1.8', '', True)] | ||
|
|
||
| This has a couple of advantages: | ||
|
|
||
| * it helps with avoiding version conflicts on the ``Java`` dependency used by two (or more) otherwise independent | ||
| module files; | ||
|
|
||
| * it allows to perform an in-place update of the ``Java`` wrapper to a more recent ``Java`` (bugfix) release | ||
| in the blink of an eye, since it only involves re-generating a ``.modulerc`` file (as opposed to performing | ||
| actual installation and generating a module file); in addition, it doesn't require updating/re-generating existing | ||
| module files that depend on the ``Java`` wrapper (since the version of the wrapper does not change) | ||
|
|
||
| Since ``ModuleRC`` is a generic easyblock , it can also be employed to install module "wrappers" for dependencies. | ||
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only Lmod 7.8 or later