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

option to disable consistency or implicit requirements #260

Closed
xdelaruelle opened this issue Apr 16, 2019 · 9 comments
Closed

option to disable consistency or implicit requirements #260

xdelaruelle opened this issue Apr 16, 2019 · 9 comments
Milestone

Comments

@xdelaruelle
Copy link
Member

Following this mailing-list discussion.

People may desire to keep by default old Modules behavior where consistency was not ensured. An option to disable either module consistency or just implicit requirements seems welcomed in specific situation.

@ikirker
Copy link

ikirker commented Oct 15, 2020

We've also been affected by this behaviour, since we use modules to implement what we call "bundles" but what have elsewhere been called collections or baseline sets: modules that load collections of modules but don't actually depend on them.

So, e.g. we have default-modules/<version> modules that load up our current default Intel compiler version and rcps-core/<version>, which itself loads current versions of cmake, git, text editors, etc.

Once you've loaded these, you can't then unload any of their parts because you get that prereq error, e.g.:

$ module unload nano
Unloading nano/2.4.2
  ERROR: nano/2.4.2 cannot be unloaded due to a prereq.
    HINT: Might try "module unload rcps-core/1.0.0" first.

It was pretty confusing to me that there is this behaviour but also the prereq + "auto" behaviour which does almost the same thing.

To be honest, I think using modulefiles is a more sensible and flexible way to implement collections than the current collections feature, but maybe an option to load and unload that can be used in bundle/collection modules would cover the difference?

Maybe one of:

module load --no-enforce <module>
module load --not-req <module>
module load --soft <module>

These also might be set to raise warnings rather than errors if they can't be loaded/unloaded when the parent module is.


As a side note, it seems like this behaviour isn't documented under the load subcommand for the module command or the corresponding entry in modulefile, which it probably should be.

If I get the chance, I'll add that and submit a PR, unless someone else gets to it first.

@ikirker
Copy link

ikirker commented Oct 15, 2020

(Just noting as I read through the docs: it even recommends that people use the approach we used, with no mention of the problems we now have.)

@xdelaruelle
Copy link
Member Author

@ikirker Thanks for your input. Having a specific command-line switch on module load or module unload seems feasible to express that no dependency relation should be recorded for the module to load or unload.

On current versions of Modules, the source sub-command may be used on these bundle modules. source evaluates specified script file like a modulefile but it does not record it in the loaded module list. So the modules loaded by the bundle are found afterward loaded on a module list but the bundle module itself is not listed (which is fine as soon as one does not expect consistency between the element of the bundle). The only downside of the source sub-command is that it requires the modulefile to be expressed as a fully qualified path name.

@xdelaruelle
Copy link
Member Author

I will add a --not-req option to module load/unload/switch commands when used in modulefile. I will also introduce an implicit_requirement option (that could be set at ./configure time or later with config sub-command) to globally disable these implicit requirements coming from the use of module load/unload/switch in modulefiles.

@xdelaruelle xdelaruelle added this to the 4.7 milestone Oct 18, 2020
@wenzler
Copy link

wenzler commented Oct 18, 2020

There is no option to disable dependency checks on unload overall or?

@xdelaruelle
Copy link
Member Author

@wenzler the result of the checks can be by-passed with the --force command-line option. With --not-req no dependency requirement will be recorded, so the unload phase will not check anything for the modules loaded with the --not-req option.

@wenzler
Copy link

wenzler commented Oct 19, 2020

I always thought MODULE_AUTO_HANDLING=0 was exactly disabling this MODULES_MPREREQ use
It doesn't do anything for 4.5.2 - even when i configure it in siteconfig.tcl or using --no-auto

So with 4.5.3 do I get this right that even this wouldnt help and I need to wait for 4.7.0?
./configure --disable-libtclenvmodules --disable-auto-handling --disable-dependency-tracking
Just checked - same behaviour in 4.5.3 with above configure options

Having modules used as module collections is quite common and people subtract what they really need later on. :/

Could you then make this a configure option in 4.7, please?
I really need to be as close as possible to 3.x behaviour.

Thanks

@xdelaruelle
Copy link
Member Author

--disable-dependency-tracking is something related to automake, used at build stage and not related to the way of handling modules.

The auto_handling configuration option (which could be disabled/enabled with MODULES_AUTO_HANDLING environment variable) controls the ability to perform some extra module load or unload to satisfy the requirements expressed by modulefiles. Even if auto_handling is disabled, the requirement consistency is enforced unless if it is by-passed with the --force command-line option.

It will be possible to set the implicit_requirement option described here at ./configure time with the --disable-implicit-requirement option.

@wenzler
Copy link

wenzler commented Oct 19, 2020

Thanks for the clarification

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

3 participants