Module conflicts are ignored in module mappings

[vkarak]

In the following example PrgEnv-gnu loads gcc/9.2.0. Using the following mapping -M 'PrgEnv-gnu: PrgEnv-gnu gcc/8.3.0' it will cause the error when loading gcc/8.3.0:

gcc/8.3.0(3):ERROR:150: Module 'gcc/8.3.0' conflicts with the currently loaded module(s) 'gcc/9.2.0'
gcc/8.3.0(3):ERROR:102: Tcl command execution failed: conflict gcc

The problem is that the mapping module mechanism is not taking into account module conflicts in mappings. In this case the rhs of the mapping will PrgEnv-gnu with gcc/9.2.0 and then it will try to load gcc/8.3.0, which will cause the error.

I don't know if this is easily fixable, but I am creating this issue to be listed as known issue at least. If we decide not to fix it, we should document it.

[teojgo]

@vkarak, this seems to be happening in general when the modules given for the tests have conflicts. For example in the test that you describe, if you define:
self.modules = ['gcc/8.3.0'] you get in any case the error. Do you think we should have a preprocessing step to check for conflicts between all the modules of the check, taking into account the mapping?

[vkarak]

Yes, but how that could be implemented nicely? Conflicts are handled at the environment level.

[teojgo]

We could have a first step to check the modules that the test is going to load and if there are conflicts between them and throw and error/warning. The user should be aware that he is asking for modules that have conflicts between them.

[vkarak]

I don't think such a step is needed. If the modules in self.modules have conflicts, the test will fail in the "setup" phase already. I think the problem is that there is no straightforward way, currently, for a user to unload a module. But this is a different problem; I don't know whether this is needed or not. Let's focus only on the module mappings for the moment. I don't know how these two are connected. Also, conceptually, I think they are two different things.

[vkarak]

I think the problem in self.modules comes from the fact that we are not searching recursively for conflicts. So gcc/8.3.0 does not conflict with PrgEnv-gnu directly, but it conflicts with gcc/9.0.2 that PrgEnv-gnu is loading. There is the problem. But even if we had this, it wouldn't solve the mapping issue, because mappings are applied at the lowest level, when a module is actually being loaded.

[teojgo]

@vkarak, that's why I think we could have a step that does this recursive resolution taking the mapping into account.

[vkarak]

Ok, I didn't get exactly your initial point. We can discuss the details offline.