Hi Sander, > I am looking for something like an identity function, and not arbitrary > kinds. That is, I want to know if elements are of the same kind or not. > This is the only thing I could come up with so far for that purpose: > > class BazelElement(BuildElement): > ... > def _is_bazel_kind(self, element: "Element"): > # This element (self) is of the bazel kind, use that to test > return self.get_kind() == element.get_kind() > > > > This has come up several times since, and has been pointed out on the > > infamous issue regarding plugins accessing unstable plugin API: > > > > https://gitlab.com/BuildStream/bst-plugins-experimental/-/issues/2 > > > > I.e. you cannot assume which plugin implements a given "kind", only the > > declaring project knows what it used for a given "kind".
<snip> > > If this is the case, and imagining that we already have something like > > "Plugin.get_identity()", then we could achieve this kind of filtering > > with a simple list comprehension: > > > > class Bazel(Element): > > > > ... > > > > # To be defined: probably a plugin identity would be encoded > > # directly into the plugin class data. > > # > > BST_PLUGIN_IDENTITY = "com.google.bazel" > > > > ... > > > > def configure(self, node): > > > > ... > > > > # Collect the bazel dependencies > > # > > self.bazel_dependencies = [ > > element > > for element in self.dependencies(Scope.BUILD) > > if element.get_identity() == "com.google.bazel" > > ] > > > > Couldn't we solve this in a more generic way without having to specify a > BST_PLUGIN_IDENTITY which now would need to guarantee uniqueness etc? > > Something like the following on Element: > > def is_same_kind(self, element): > return self.__class__ is element.__class__ > > That should do the trick? I'm not necessarily against having some sort of identity function. Although, for purposes like this, I wonder if an interface would be better suited than identity function. Just to throw this idea out there. Instead of doing conditional checks in the would-be Bazel plugin, perhaps it could define an interface, saying that all bazel elements need to write something in their public data. So, rather than checking the element plugin's identity, Bazel plugin would read that public data and make necessary assumptions. If it's not a Bazel plugin, it would lack that public data section, so Bazel plugin could treat that as a normal element. This is a small difference implementation-wise, but I think this approach can lend itself towards more generic solutions. This is a hypothetical example, but bear with me for a moment. Imagine there are two similar plugins - bazel and experimental-bazel. They are largely the same but maybe one of them implements a special performance optimization. Using identities would mean that these two plugins won't be able to take advantage of the optimization based on being of a bazel kind, or would have to have the same identity (which seems a bit wrong). Alternatively, with using public data, both plugins could write necessary markers to some predefined public data domain. Let me know what you think. Cheers, Chandan
