closing-reopening

@smoors Can you clarify the use case for this? What's the point of generating a module file you can't load?

Also, this is for using together with --force --module-only, right? Since otherwise the generated module will be loaded during the sanity check, which will result in a failure if the module can't be loaded.

I would rename it too, since it's a boolean option. It should be something like --generate-devel-module that is enabled by default, and then you can use --disable-generate-devel-module.

That being said, I think we need to re-evaluate generating those devel modules, I doubt they're actually useful at all (see also #109).

@boegel my use case is discoverability:
you could make a module visible to the user e.g. when they do 'module spider' or 'module av' on the login node, without allowing them to actually load/use it on the login node itself. when the user tries to load it they then get an error message saying 'this module can only be used on this type of node'. currently we work around this by creating a LmodWarning but imho this is confusing for the users because then they have loaded a module that does not do anything, while still having loaded its dependencies.

it should indeed be used together with --force.

renaming the is fine to me, I was not happy about the name in the first place.

about the usefulness of devel modules, I never used them myself, if they work at all. maybe we can ask the community to see if anyone is using them?

closing-reopening

@boegel any objections to merging this PR?
is an additional test needed?
can we merge this now and worry about the fate of the devel modules later?