Make specifying exts_defaultclass
optional
#4800
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is NOT required when all extensions have either custom easyblocks or an
easyblock
key in their option dict.In those cases
exts_defaultclass
is redundant making it harder to write the EasyConfig.Check for a missing easyblock when actually using it so the error will be just a bit later but still (almost) the same.
One noteworthy semi-related change is the try-finally to the
clean_up_fake_module
call. We did that only when the exts_defaultclass was missing but not when anything else fails which looks like an omission. To keep at least the behavior for this the try-finally is required as the exception comes frominit_ext_instances
now. As a (IMO good) side effect it will also be called for any other error happening along the way, e.g. the similar error that the default easyblock is not foundAlso some small drive-by fixes without any functional change to reduce the amount of linter warnings in the touched files.
Recent example usage for a CMakePythonPackage Easyconfig:
But also applies if only software-specific easyblocks are used and we really don't want a default