@ocaisa OK, I think this is ready... Can you take a close look at these changes?

@ocaisa well, with --use-existing-modules the toolchain being picked would also depend on which modules are available even without --minimal-toolchain with this in place, no?
This PR doesn't change anything if --minimal-toolchains is used, only when it is not used.

I've been thinking about enabling --minimal-toolchains by default: I think it mostly makes sense when you have a non-flat module tree...
With a flat module tree, using subtoolchains for stuff like CMake & co actually complicates things for users, since they need to figure out which toolchains are compatible with each other (e.g. which GCC module can be loaded if a particular foss toolchain is loaded, which gompi matches with the active foss, etc.).

So, would it make sense to enable --minimal-toolchains conditionally based on the module naming scheme being used?
That would only be the default way of configuring things of course, you can always override that using either --minimal-toolchains or --disable-minimal-toolchains.

But then it would have no net effect, even for a hierarchical scheme, if you include easyconfigs in the repo with the full toolchain then it will always chose those.

Maybe it is time to update the default MNS? Who in their right mind would chose a flat scheme anyway? ;)

@ocaisa the effect this change has is that easyconfigs that were contributed by a site that is using --minimal-toolchains can be consumed easily by sites not using it (with the only 'downside' that full toolchains aren't used for all dependencies, depending on your view).

I guess this is where support for fat easyconfigs where you can list compatible toolchains comes back into view. Or even support for telling the robot to build with a full toolchain even when only an easyconfig for a subtoolchain is available (since if building with gompi works, then it should also build with foss). But then spending effort on the former would make more sense imho...

I'm not sure if switching to HierarchicalMNS by default is a good idea, you need to be aware what a hierarchical MNS entails and opt-in to it, imho... It's not entirely trivial.

Sure, but watering things down means we are still wide open to the proliferation of easyconfigs rather than making sure we collaborate on a minimal number.

I agree that fat easyconfigs are the site-agnostic solution (and a step in the right direction in general), just have to find the time to implement. Can we make the default in EB 3.0 to prefer .yeb over .eb? Then we can progressively implement yeb support (maybe holding back .yebs in a separate branch until we're happy with how they work).

If we go the path discussed in https://github.com/hpcugent/easybuild/wiki/Conference-call-notes-20160817 then preferring yeb would just mean making sure that when a .yeb is decomposed into .ebs that the temporary path comes first in the robot search

@ocaisa Currently the robot doesn't consider .yeb at all. Not sure if squeezing that in now is a good approach...

Which .yeb easyconfig filenames should it consider when looking for, say, CMake 3.5.0 when using foss/2016b as toolchain? Certainly CMake-3.5.0.yeb and CMake.yeb, in that order? Any others? CMake-3.yeb? CMake-3.5.yeb? CMake-foss.yeb? CMake-3-foss.yeb? CMake-3.5.1-foss-2016b.yeb? And then I'm not even considering versionsuffix yet. How far do we want to take this?

Also, this discussion is starting to diverge from what this PR is trying to do, I think.

It's clear that more works is required to make both sites that prefer using subtoolchains where appropriate and sites that usually stick to 'full' toolchains happy, and I see the changes made in this PR as a (small) step in that direction.
The biggest leap would indeed be support for fat .yeb easyconfigs, but that's not going to happen for EB v3.0, that's clear I think... I'm happy to discuss this further through (a subissue of) #1407.

The format for fat yeb is as yet undecided isn't it, it can be decided in such a way as to be unique (e.g., only fat wrt toolchains would be unique for software/version/versionsuffix). You could pull the rest of the cleverness into the framework if you wanted to go fat in other directions...but ok that's a chat for another thread.

This PR has value and should still be merged but it skirts around the reason I created minimal toolchain in the first place: to minimise the amount of easyconfigs I have to work with to create an entire software stack for our system. If eb doesn't encourage people to transition to submitting easyconfigs with the appropriate toolchain then this number won't go down and we'll still have people solving the same problems over and over with different toolchains (not necessarily in the release repo, but certainly if they're managing their own deck)

@ocaisa I think the problem is that "the appropriate toolchain" means different things for different sites.
I fully agree that using the most minimal toolchain makes perfect sense in a module hierarchy, but as I mentioned I feel it may complicate things when a flat module tree is used since users would have a harder time figuring out which modules are compatible with each other...

So, I think working towards fat easyconfigs is the right approach to deal with this, I think we're on the same page there.

This PR doesn't really help there, but it's a way to make sure that people can pick up easyconfigs that were contributed by a site that is using --minimal-toolchains; without this, those easyconfigs can't be consumed as-is, the toolchains would have to be tweaked manually for the robot to be able to resolve dependencies (when having --minimal-toolchains disabled).

I hope this change can motivate sites using --minimal-toolchains to contribute back their easyconfigs. I actually feel it's a step towards making people at least think about minimal vs full toolchains for dependencies, rather than only considering the toolchain of the parent by default.

I suggest we merge this as is, and discuss whether or not we want to enable --minimal-toolchains by default or not during the next EasyBuild conf call, and also start planning how/what to implement support for 'fat' .yeb easyconfigs...

Happy to merge, backwards compatible and improves behaviour so lgtm

OK, thanks for the feedback @ocaisa!