depends_on doesn't survive module swap

[vanderwb]

The documented behavior for depends_on suggests that a listed dependency will only be unloaded when the original package is unloaded if the dependency was not already loaded before loading the package. This works well in normal situations. However, if you perform a module swap on a package higher in the hierarchy (e.g., a compiler), the packages are reloaded explicitly and the fact that the dependency was loaded as such is lost. This means that unloading the package will not unload the dependency in situations when it should, after such a swap.

To Reproduce

Consider the following module tree:

.
├── compiler_a
│   ├── dependency
│   │   └── 1.0.lua
│   └── package
│       └── 1.0.lua
├── compiler_b
│   ├── dependency
│   │   └── 1.0.lua
│   └── package
│       └── 1.0.lua
├── Core
│   ├── compiler_a
│   │   └── 1.0.lua
│   └── compiler_b
│       └── 1.0.lua

Here, package depends_on dependency.

Let's run though some commands:

module list
module unload package
module list
module load package
module list
module load compiler_b
module list
module unload package
module list

Here is what we get:

Currently Loaded Modules:
  1) compiler_a/1.0   2) dependency/1.0   3) package/1.0

Currently Loaded Modules:
  1) compiler_a/1.0

Currently Loaded Modules:
  1) compiler_a/1.0   2) dependency/1.0   3) package/1.0

Lmod is automatically replacing "compiler_a/1.0" with "compiler_b/1.0".

Due to MODULEPATH changes, the following have been reloaded:
  1) dependency/1.0     2) package/1.0

Currently Loaded Modules:
  1) compiler_b/1.0   2) dependency/1.0   3) package/1.0

Currently Loaded Modules:
  1) compiler_b/1.0   2) dependency/1.0

Expected behavior

I'm not sure what the expected behavior is here. However, the desired behavior would be for the knowledge that dependency was loaded because of a depends_on condition in package to survive the swap operation, and thus cause the unload behavior to be consistent.

Desktop (please complete the following information):

• OS: Linux
• Linux distribution: SLES 15
• Lmod Version: 8.7.2

[rtmclay]

Thanks for the detailed bug report. It will really speed up the opportunity to look at this bug if you would follow the instructions give in the bug report template and provide an actual modulefile tree that shows the issue you are having.

If you are having an issue with a moduletree that is using the hierarchy consider using the moduletree provided in the source repo: To use do the following:

• copy bugReport directory tree from the repo to your own directory
• modify as necessary the modules under the my_modules directory
• modify the bug_report_template.sh script to show your issue
• Run the script this way:

$ env -i LMOD_ROOT=$LMOD_ROOT USER=$USER ./bug_report_template.sh

[vanderwb]

Hi @rtmclay - just to be clear... do you prefer that I use the "gcc" and "mpich" modules in the bug_report_template instead the modules I've created above, or are you just asking that I copy my test modules into the bugReport/my_modules (replacing the sample ones) and put my run commands into the bug_report_template.sh script?

[rtmclay]

Feel free to use your modules that you have created. What I want is be able to reproduce the bug. I do not care what the module names are. The gcc and mpich modules are there to make it to make it easy for sites to build a test hierarchical module layout.

[vanderwb]

@rtmclay I have put my modules and commands into the desired form.

bugReport.tar.gz

[rtmclay]

Thanks for using the bug report guidelines! It was a big help. This was a difficult bug to track-down although the code changes were small. I had to completely re-think how dependency work.

I have updated the testing branch which has fixed this issue for me. Please test this branch and let me know if this fixes the bug for you.

[vanderwb]

Awesome. I will give this a try early next week and get back to you.

[vanderwb]

Finally had a chance to test this and it looks good in the testing branch. Thanks!

[rtmclay]

Great! This bug fix will be part of Lmod 8.7.14. This will be available next week.

[rtmclay]

It turns out that there were more issues with depends_on() and the software hierarchy. If you get a chance, please test Lmod 8.7.14

[vanderwb]

Hi @rtmclay - thanks for the robust addition. Version 8.7.14 gives us the behavior we want.

[rtmclay]

@vanderwb - You are very welcome. This was a big deal to fix.