Hi, Thanks for the engaging replies :).
On Fri, Jul 31, 2020 at 2:27 PM Tristan Van Berkom < [email protected]> wrote: > Hi Chandan, > > On Fri, 2020-07-31 at 13:02 +0100, Chandan Singh wrote: > > Hi Sander, [...] > > 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? > 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). > I think that's fair. > Alternatively, with using public data, both plugins could write > > necessary markers to some predefined public data domain. > > > Let me know what you think. > That sounds like an interesting approach. I'll dig a bit to see how to make that work. It sounds promising. > Pretty much the same thing crossed my mind when originally replying, I > think this can be done today without much hassle. > > That said, baring in mind that we might want plugin identities for > other reasons, it might be a better approach to use plugin > identities... on the other hand, we might find that any requirement > that would be satisfied by identities would also be satisfied by public > data markers. > > Lets first collect all the pertinent use cases and see what is the > better solution :) > +1. Curious about the other use cases. > Cheers, > -Tristan > Cheers, Sander
