fix double initialization of Cargo by CargoPythonPackage by removing incorrect custom __init__ implementation + fix use of super() in PALM easyblock (since that doesn't work with Python 2.7)#3406
Conversation
The issue intended to be fixed with easybuilders#2934 is actually caused by Pythons MRO: CargoPythonPackage explicitely calls `__init__` of **both** `Cargo` and `PythonPackage` 1. `super().__init__` in Cargo calls `ExtensionEasyBlock->EasyBlock` stop (Could then call `Extension` but `ExtensionEasyBlock does not use `super`) 2. Then `PythonPackage.__init__` is called by `CargoPythonPackage` 3. `super().__init__` in PythonPackage calls `Cargo.__init__` again(!) 4. Then all other methods are called again as per 1. The MRO order is `[CargoPythonPackage, PythonPackage, Cargo, ExtensionEasyBlock, EasyBlock, Extension]` which explains that. Fix is to consistently use `super()` in the CargoPythonPackage inheritance chain.
|
Please have a look at this @boegel @Micket (involved in #2934) Related easyconfig PR: easybuilders/easybuild-easyconfigs#21143 |
| """Constructor for CargoPythonPackage easyblock.""" | ||
| Cargo.__init__(self, *args, **kwargs) | ||
| PythonPackage.__init__(self, *args, **kwargs) | ||
| super().__init__(*args, **kwargs) |
There was a problem hiding this comment.
This looks very sensible, but I seem to remember there was a reason why we didn't do it like this initially...
@Micket Do you recall why we implemented it like this?
There was a problem hiding this comment.
I don't recall any details here, if there some order that had to be forced or not, or maybe it was just duplicated from configuremakepythonpackage.py.
If it works it works, that's all that matters, so go ahead and fix this.
|
As discussed in the confcall I made that compatible with Python 2 which doesn't support argument-less I found another instance of that in Palm and an |
boegel
changed the title
Cargo by CargoPythonPackageCargo by CargoPythonPackage by removing incorrect custom __init__ implementation + fix use of super() in PALM easyblock (since that doesn't work with Python 2.7)
|
@boegelbot please test @ jsc-zen3 |
|
@boegel: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 2288342661 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot Overview of tested easyconfigs (in order)
Build succeeded for 1 out of 1 (1 easyconfigs in total) |
4 participants
The issue intended to be fixed with #2934 is actually (likely) caused by Pythons MRO:
CargoPythonPackage explicitely calls
__init__of bothCargoandPythonPackagesuper().__init__in Cargo callsExtensionEasyBlock->EasyBlockstop (Could then callExtensionbutExtensionEasyBlock does not usesuper`)PythonPackage.__init__is called byCargoPythonPackagesuper().__init__in PythonPackage callsCargo.__init__again(!)The MRO order is
[CargoPythonPackage, PythonPackage, Cargo, ExtensionEasyBlock, EasyBlock, Extension]which explains that.Fix is to consistently use
super()in the CargoPythonPackage inheritance chain.