Ignore other classes if software specific easyblock class was found #4769
Conversation
If we have other classes next to a software specific easyblock class in an easyblock file they are likely supplemental. So ignore them in `avail_easyblocks`.
- Reduce indentation - Assign directly to dict
| if len(class_names) > 1: | ||
| # If there is exactly one software specific easyblock we use that | ||
| sw_specific_class_names = [name for name in class_names | ||
| if not is_generic_easyblock(name)] | ||
| if len(sw_specific_class_names) == 1: | ||
| class_names = sw_specific_class_names |
There was a problem hiding this comment.
This could possibly be improved to allow additional classes in a generic easyblock by checking if pkg is easybuild.easyblocks.generic and comparing the class_names with the filename
There was a problem hiding this comment.
Good point. Implemented. By testing I also found that our (for some reason multi-line regex) would match:
class Foo:
pass
class Bar(EasyBlock):
pass
Resulting in the "class_names" Foo:\n pass\n\n\nclass Bar because it finishes only at parentheses not the colon
That was fine for Python2 where the parentheses were mandatory in all cases
The class name regex is MULTILINE and hence might start a match at a class name without a super-class and match until another class name with a super-class Restrict by excluding colons in addition to parentheses Also add test for this and the multi-class case to a generic easyblock
Unrelated class in an easyblock file have the same package name as the easyblock and hence the filter doesn't remove them. Instead of the package name check if the class derives from `EasyBlock` which is a much more reliable check whether the class is an EasyBlock.
|
Through the latest error I've found a duplication of the logic:
I'd say we should only use the logic from |
Flamefire
force-pushed
the
multi-class-easyblocks
branch
from
992e175 to
94b9a72
Compare
|
@akesandgren Shall we fix the duplication issue here, in a separate PR or not at all? I'd say in a follow-up |
I assume you meant If so let's push that to a separate PR |
Indeed. It's seemingly C&P-mistake-monday ;-) Fixed so the description makes sense |
|
This now looks good to me |
…asyblocks based on 'EB_' prefix
@boegel Shall I do that PR? |
If we have other classes next to a software specific easyblock class in an easyblock file they are likely supplemental.
So ignore them in
avail_easyblocks.Also 2 cleanups:
EB_in all places