Heya! Just a quick inline reply to clarify one point.
> > > 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. > > > > When you say "that all bazel elements need to write something in their > public data" do you mean that the plugin would write that public data in > its artifact, and read it again when consuming such and artifact as a > dependency? Exactly. The bazel plugin will first define some sort of interface on what it will expect from the public data AND be responsible for encoding the same for elements that are of the bazel kind. After that, if some other bazel-like plugin wants to pretend as a bazel plugin, it can also write similar public data to elements of its kind. And, the bazel plugin will happily consume artifacts of bazel-like plugin, same as it would consume artifacts of a bazel plugin. Again, this is a bit of a contrived example and it'll be good to understand other use cases as well. But, I think we can get away with reading/writing public data using plugin-defined interfaces rather than having the need for an identity function (although that may be needed for other reasons). - Chandan
