Incorrect `no-member` linter errors from cython modules
Follow-up from "Refactor: Lazily instantiate ProvenanceInformation objects"
The following discussion from !2026 (merged) should be addressed:
-
@BenjaminSchubert started a discussion: (+1 comment) @tristanvb I've look into the linting error more, I can't figure out why it does fail.
At that point I'd suggest extracing the
top_element.link_target.as_str()
in a variable and silence pylint for that error on the line
Follow up comment
I chased this down the rabbit hole a bit, and stumbled on this post, and discovered we are whitelisting our cython modules to be loaded by the linter and telling the linter to enable c-extension-no-member
.
I was also unable to get to the bottom of it, it seems we are hitting some kind of edge case, and I think a hint is that the errors themselves are incorrect, if I remove all the disabling of no-member
in loader.py
:
src/buildstream/_loader/loader.py:149:8: E1101: Class 'dependencies' has no 'extend' member (no-member)
src/buildstream/_loader/loader.py:354:26: E1101: Class 'link_target' has no 'as_str' member (no-member)
src/buildstream/_loader/loader.py:392:27: E1101: Class 'node' has no 'get_str' member (no-member)
In each case, the linter is mistaking a variable name for a class, the error in question should be printed as:
src/buildstream/_loader/loader.py:354:26: E1101: Class 'ScalarNode' has no 'as_str' member (no-member)
But the linter instead thinks the reference to the instance link_target
is itself the ScalarNode
class.
In any case, for now I will just disable the error as you suggest.