Rename modulename to load_name for Extensions and allow as root-parameter

[Flamefire]

This replaces the misleading modulename by load_name as it is used to test-load the module/package/software although the naming might differ:

• Julia Modules
• Python & Perl packages
• import
• require
• list | grep

load should still be generic enough.

I also deprecated passing a dict to collect_exts_file_info and get_modulenames: We don't need that and it just complicates things in the function: We always have an extension at that point. I don't see where a dict with an options key could even come from.

Fixes #493

Initial draft done by AI, manually verified and adjusted afterwards

Based on

• Add factory method make_deprecated_dict_class for creating a dict with deprecated/replaced keys #5260
• Initialize name and version in EasyConfig instance of Extension #5267

So those should be merged first

[smoors]

also needs fixes in easyblocks that use self.options['modulename']?

[Flamefire]

Indeed. That might actually be an issue:

• User sets load_name
• easyblock defaults modulename to something
  -> conflict

I'll check if I can come up with eg. a dict-wrapper that redirects reads and writes to load_name

[Flamefire]

Ok I added "aliasing" code now.
This allows
a) Setting self.options['modulename'] resulting in load_name being set (instead)
b) Set self.options = {'modulename': 'Foo'} with the same effect

[Flamefire]

Once this gets merged I'll update the affected easyblocks

[boegel]

• should use extension_name as default value (see Add extension_name easyconfig parameter, to specify name of extension to use in generated module file #5259);
• should be top-level maybe (also for things that don't derive from ExtensionEasyBlock)?

[smoors]

note that for PythonPackage it's not just the extension_name but lower().replace('-', '_')
https://github.com/easybuilders/easybuild-easyblocks/blob/219fb2b77eb9f21efb360406f489896c372f3315/easybuild/easyblocks/generic/pythonpackage.py#L588

[Flamefire]

Yes I'd say we keep that logic elsewhere. In Pythonpackage we can overwrite the default:

• Use if set
• If extension_name is set use that
• Else use name.lower().replace('-', '_')

But I think the 2nd step (extension_name, then name) makes sense

[Flamefire]

Ok, I added the extension_name-as-default-load_name commit. That was quite a bit of work to get all cases right. In the end I could just propagate extension_name from the ExtensionEasyBlock to self.options and covered all cases I could think of in tests

#5260 is still included here

[Flamefire]

On second thought this is not the right way: we should NOT use self.options and try duplicating the Easyconfig parameter into it but rather the other way round: deprecate using it and set the value for options in the Easyconfig for backwards compatibility
Otherwise we risk the 2 values becoming out of sync: with load_name at the top level someone might set it there but we use it from self.options

Adding extension_name showed this: it is not available where we need it and duplicating it into self.options means someone might set it there

More general: do we need the Extension class at all? It seems ExtensionEasyblock is all we need together with self.is_extension. Not having to deal with both might make it easier to understand and update

[Flamefire]

I added a new commit: Deprecate self.options, options EC parameter and set all in self.cfg

That implements the idea I had above:

If we have load_name and extension_name in both self.cfg and self.options they can have differing values.
As options now are always known easyconfig parameters we only need self.cfg and can remove self.options

May need adjusting other tests too but wanted to get some feedback first.
I tried to make self.options as backwards compatible as possible. But e.g. for i in self.options, options.keys and options.items would be different because they cannot known which EC parameter would have been in there. I hence did not add them but left the basic get/set/is-in methods.

I can imagine less invasive methods only deprecating access to self.options itself for now: Ignore load_name and extension_name in options, error when we have load_name in self.cfg and modulename in options
load_name/extension_name are now so that is valid, but can still lead to silent issues when users update by just replacing modulename to load_name

[Flamefire]

@boegel @smoors Fixing the tests is just a small chore. Do you agree with the proposed solution:

• self.options deprecated
• Reads writes go to self.cfg
• Using non-cfg parameters in self.options is deprecated. Currently handled by a local dict for unknown params
• self.options is only mostly backwards compatible

This provides us a clear and clean way forward. I guess there was intention to have plain Extension instances but that wouldn't even work anymore. Every extension is actually an ExtensionEasyBlock. Only reason to keep Extension might be circular imports when checking if an ext_instance is an Extension(EasyBlock) done inside easyblock.py which is also imported from extensioneasyblock.py. Users shouldn't actually instantiate the class. We could deprecate the __init__ method and call an _setup method from ExtensionEasyBlock or set up everything from there. Currently it is a bit messy what parts are set by which of the 2 classes __init__ functions

[smoors]

+1 from me for deprecating self.options, but i don't feel qualified enough to review this big PR.

[Flamefire]

Sorry, this was pretty complicated to keep backwards compatibility.
I moved a bit more to #5260
Maybe I can factor out the options deprecation but I think that won't work without allowing modulename at the root first which shouldn't be done without the deprecation and remapping machinery.
I also created #5291 with commits that work without this PR and will rebase this one after those 2

[boegel]

We need to get EasyBuild v5.4.1 ASAP (it's way overdue), so I'm moving this one to the next milestone (release after v5.4.1)...