Skip to content
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

Add ability to set downstream defaults when a module is loaded #679

Open
jcsiadal opened this issue Dec 2, 2023 · 2 comments
Open

Add ability to set downstream defaults when a module is loaded #679

jcsiadal opened this issue Dec 2, 2023 · 2 comments

Comments

@jcsiadal
Copy link

jcsiadal commented Dec 2, 2023

SUMMARY

Provide a mechanism to set defaults for other modules at the time a new module is loaded. Instead of module defaults being purely static, allow for dynamic configuration of defaults. While Lmod supports a hierarchical environment tree, there is no way for modules to control loading the correct version of downstream modules, since Lmod will simply default to the latest or locally defined default, even if the downstream version of something is not validated (or doesn't work) against the upstream version.

Example

Let's say we have the following module hierarchy. A,B,C,D are directories of modules for apps and libraries and C and D are on read-only remote shares (no admin control). When A is loaded, it adds B to the module path, B adds C, etc. All versions of each lib or app module are in the same directory (typical setup).

A -> B -> | C -> D

When a specific version of module A is loaded, there is no way for a matching, validated, version of C and D to be loaded automatically, other than modifying each module in the chain. I don't see a way for a user to get a fully validated toolchain automatically, other than to load the entire chain in a single module file.

If a user loads an older version of library A, then there should be a way for Lmod to load the correct older module versions of B, C, and D, but only when/if the user loads them.

Desired behavior

The ideal fix is for the "module_version()" function to work directly in regular modules. It should override all other behavior for defaults.

Another option is to make $LMOD_MODULERC dynamic, so it can point to a different file with downstream defaults defined.

As a side note, the "conflict()" function needs to operate downstream and support versioning. That is, a module should not load if a conflict for that module or module/version has been set by a previous module.

@rtmclay
Copy link
Member

rtmclay commented Dec 4, 2023

Thanks for submitting this. Your desired behavior is to use "module_version()". It is not clear to me what you want to happen. Currently, the "module_version()" function returns the current version of the module being loaded. Please explain how this would work and please use concrete examples. Also, it is unclear what you mean by how conflict() would now work. Thanks!

rtmclay pushed a commit that referenced this issue Mar 19, 2024
rtmclay pushed a commit that referenced this issue Mar 28, 2024
rtmclay pushed a commit that referenced this issue Mar 28, 2024
@rtmclay
Copy link
Member

rtmclay commented Mar 29, 2024

Support for downstream conflicts added. To use configure Lmod with --downstreamConflicts=yes in the PR679 branch

Note that there is no new conflict() function. With the configure option conflicts() are support both current conflicts and downstream conflicts.

There is no support for downstream defaults yet.

rtmclay pushed a commit that referenced this issue Apr 4, 2024
rtmclay pushed a commit that referenced this issue Apr 4, 2024
rtmclay pushed a commit that referenced this issue Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants