Hi,
On Thu, Jul 30, 2020 at 11:45 AM Tristan Van Berkom <
[email protected]> wrote:
[...]
> Regarding:
>
> "ways to identify elements that do or do not match the same kind as
> the plugin"
>
> I think this pertains to the Bazel plugin issue you discuss below,
> otherwise I'm not sure what you mean by this :)
>
That was what I meant :).
[...]
> > I've sadly stalled on progress on a bazel plugin[5] that I started for
> > research/discovery reasons as outlined in Chandan's summary message[0].
> > However, even in its current very WIP form, it raises some questions on
> how
> > to do certain things. Like filter all dependencies of the same kind, to
> > stage them differently. I imagine that some of this work would end up
> > being split between stage() and configure_dependencies() following your
> > proposal?
>
> Filtering elements based on the same "kind" is a misguided approach, as
> the element "kind" is not indicative of the nature of the actual plugin
> being used.
>
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".
>
> Interestingly, Ben and I have discussed this fairly recently on IRC and
> we do agree that it would be useful for plugins to have some kind of
> identity encoded into them which could be used for this kind of
> conditional treatment of dependencies. I imagine a kind of domain name
> format might be suitable for unique plugin identities, e.g.:
>
> "org.buildstream.git" <-- indicates the "git" plugin maintained by
> BuildStream
>
> That said, I imagine that for the Bazel use case you describe, an
> identity filtering would be more user friendly, I'm not certain of all
> the details but I think you really want to filter dependencies based on
> a specific plugin identity rather than requiring the user to explicitly
> decide which dependencies get treated a certain way.
>
That's exactly right.
> 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?
Cheers,
Sander
