-
Notifications
You must be signed in to change notification settings - Fork 109
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
modules test not performing loads #436
Comments
Hi, Could you explain why Best, |
@adrien-cotte It is my understanding that there is no real difference between However, if that setting is not enabled then In any event, I tested this case with both |
Ok, sorry as my config always been auto_handling on, I forget this is not the default behavior :) Btw, I never test unloaded modules, is there any reason you cannot load your module before calling With your example:
I don't really know why we have to load modules before testing, maybe we should ask of Module mailing list? Does this workaround work for you? |
In many (most?) cases it's probably not necessary to load the modulefile. Having to do so seems cumbersome to me, as you'd (perhaps) have to be careful to Would the maintainers be interested in a PR to fix this issue? If so, is it necessary to be backward compatible with the existing behavior? |
The Lines 90 to 130 in 3bc7b99
PR would be interesting to add the proposed new behavior. I still need to think if this should be the new default behavior or if an option is needed to enable such change. |
So, actually |
After some thought, I suggest the addition of a new configuration option, named @ben-bowers You can follow the Add new configuration option guide to craft this pull request. |
I believe I have something that barely works. The change to the Tcl is relatively small, but the files that needed to be updated were quite large. Thanks for the excellent Add New configuration option guide! One place I find that it is not working as expected is when I switch to use the For instance, and the test_mode_mimic== #%Module1.0 # -*- tcl -*-
module load fake_base_path ## <--- doesnt evaluate this file
set toolpath [getenv BASE_PATH]/fake/bin the fake_base_path is not evaluated. However when test_mode_mimic== #%Module1.0 # -*- tcl -*-
prereq fake_base_path ## <--- works!!
set toolpath [getenv BASE_PATH]/fake/bin then the evaluation of the file happens. I had previously thought that these would have worked the same, but they call different tcl commands under the covers, so apparently it is not straightforward. The other side effects I need to figure out are:
|
For your first point, the Lines 364 to 365 in aa33eda
For the change your are crafting, I suggest you adapt the # set evaluation mode to the mode to mimic on test mode
if {$mode eq {test} && [getConf test_mode_mimic] eq {load}} {
set mode load
} This way |
For the second side effect mentioned, a This new procedure could
Then the end of the Lines 754 to 756 in aa33eda
It should be updated to something like: if {$topcall} {
# clear env changes if test mode mimics load mode
if {[currentState mode] eq {test} && [getConf test_mode_mimic] eq\
{load}} {
clearSettings
}
renderSettings
} |
For the |
Describe the bug
In an attempt to refactor modulefiles into separate common modulefiles, ModuleTests no longer operate as expected.
Presumably this is because when run in test-mode the dependent modulefiles are not loaded. Since the top level module relies on a
setenv
from the sub-modulefile, the variable evaluates incorrectly and the test fails.This may be a feature rather than a bug - but if there is some workaround, that would be helpful to know.
To Reproduce
Steps to reproduce the behavior:
For modules v4.3 to v4.7, the output is:
Location and content of any modulerc or modulefile involved:
Expected behavior
It would be convenient if sub-modulefiles are loaded as part of the
module test
so that it is possible to refactor common parts of the modulefiles. If that is considered breaking behavior, then maybe a mode that enables loads/prereq during the test?Error and debugging information
Modules version and configuration
Tested across several versions:
Additional context
The text was updated successfully, but these errors were encountered: