Support for extending graphs to contribute to select multibindings/broader "plugin" support

[rnett]

Hey there, I'm trying out metro for an application that is going to support plugins. The ability to extend graphs as a detached consumer is killer here. However, for plugins to actually be able to do anything I need extension points that plugins can register extensions to. Ideally, I'd like to use multibindings. However, understandably, extending graphs can't contribute the parent's multibindings.

---

I'd like to see whether it would be possible to allow this in an opt-in (per multi-binding site) manner. In an ideal world, it would look something like this (parts omitted for brevity):

@DependencyGraph(isExtendable = true)
interface ParentGraph {
  @Multibinds
  @ExtensionPoint
  val processorExtensions: Set<ProcessorExtension>
}

// different module

@DependencyGraph
interface MyPluginGraph {

  @Provides
  @IntoSet
  fun myProcessorExtension(): ProcessorExtension= MyProcessorExtension()

  @DependencyGraph.Factory
  fun interface Factory {
      fun create(@Extends parent: ParentGraph ): MyPluginGraph 
  }

}

and anywhere Set<ProcessorExtension> is injected would see it contain MyProcessorExtension().

In practice, I don't think this will be sufficient because the lifecycle of the plugin graph may not match the parent graph. It would be fine, for my use-case at least, if you could only bind some kind of ExtensionSet that had a .get(List<Any> subgraphs) method or something similar where you had to specify the sub-graphs up front. Perhaps the whole thing would be distinct from set bindings.

---

I have a workaround where you create a mutable ExtensionRegistry type, provide it to the parent graph, make plugin graphs extend a type that exposes a Set<BaseExtension>, and add it to the registry when the plugin initializes. However it's a bit clunky since any extension has to be bound to the BaseExtension set not the specific extension type (e.g. IrProcessorExtension). And you also can't inject Set<IrProcessorExtension> directly.

@DependencyGraph(isExtendable = true)
interface ParentGraph {
  val registry: ExtensionRegistry

  @DependencyGraph.Factory
  fun interface Factory {
    fun create(@Provides registry: ExtensionRegistry): ParentGraph
  }
}

interface BasePluginGraph {
  @Multibinds(allowEmpty = true)
  val extensions: Set<Extension>
}

interface Plugin {
  fun createGraph(parent: ParentGraph): BasePluginGraph
}

fun main() {
  val extensionRegistry = ExtensionRegistry()
  val parentGraph = createGraphFactory<ParentGraph.Factory>().create(extensionRegistry)

  ServiceLoader.load(Plugin::class.java).forEach { extensionRegistry.registerAll(it.createGraph(parentGraph).extensions) } 

}

// different module

@DependencyGraph
interface MyPluginGraph : BasePluginGraph {

  @Provides
  @IntoSet
  fun myProcessorExtension(): ProcessorExtension= MyProcessorExtension()

  @DependencyGraph.Factory
  fun interface Factory {
      fun create(@Extends parent: ParentGraph ): MyPluginGraph 
  }
}

@AutoService(Plugin::class.java)
class MyPlugin() : Plugin {
  fun createGraph(parent: ParentGraph) = createGraphFactory<MyPluginGraph.Factory>().create(parent)
}

While this works it's not pretty.

[ZacSweers]

I think the way you're doing it is the way to go, parents are always processed before children and trying to reverse that pipeline would really be pushing data the wrong way. I don't think this is a case that metro needs to have custom first party support for. Graph extensions are strictly supersets of their parents' bindings.