[rocketraman]

Kodein's authors are sunsetting Kodein in favour of Inara, a compile-time successor that runs as a KSP processor. This adds experimental Inara bindings. If they work out, we'll deprecate the Kodein bindings and point users to Inara.

What's here

• An inara flavor in configureDiVariants(), published as <module>-inara like the -kodein and -metro coordinates. Every module with Kodein bindings has one.
• Each flavor is a @DIModule (BootableModule, ConfigModule, EnvironmentModule, JdbcDataSourceModule, FlywayMigrationModule, ExposedDatabaseModule). It comes with a builder overload of the same name, which binds all of the module's members from what it needs, e.g. JdbcDataSourceModule(SqliteConfigSource, HikariPool(), bootable). Each builder takes the BootableModule as its context, typed only as ConfigModule and AppServiceAcceptor: it reads its config from it and adds its services to it. KSP runs on the flavor's source set only, so the generated builders ship in the -inara jar.
• The app composes the built modules into its own @DIModule(composed = true) and binds only its own members (composition).
• examples/wiring-inara and examples/server-ktor-db/inara, and Inara cases in boot's wiring tests.
• An "Inara (experimental)" section in docs/wiring.adoc, plus README and CHANGELOG entries.

@DIModule(composed = true)
interface AppModule : BootableModule {
  val greetingConfig: GreetingConfig
  val greetingService: GreetingService
}

fun main() = boot {
  val bootable = BootableModule(HopliteConfigModule())
  val app = AppModule(
    bootableModule = bootable,
    greetingConfig = bootable.config("greeting"),
    greetingService = Binding.single { GreetingService(greetingConfig) },
  )
  app.addAppService { app.greetingService }
  app.bootable
}

How Kodein's features map to Inara

• Multibindings. Inara has none, by design. Each module's builder takes an AppServiceAcceptor, which BootableModule implements, and adds its own services to it (after this gist). The app adds only its own, with app.addAppService { … }. The set lives in each BootableModule instance, not in a global, so tests stay isolated. Forgetting one still compiles, and that service never starts. Adding a service after the set is read throws. A compile-time locator (proposal) would replace it.
• Optional bindings. Where Kodein uses instanceOrNull, the builder takes a nullable parameter: BootableModule(configModule) reads the tiebreaker from config, BootableModule() falls back to an EmptyConfigModule, and startOrder and tiebreaker parameters set them in code.
• No diamonds. A composed module rejects shared ancestors, so only BootableModule extends ConfigModule (composed modules nest), and the app's module gets the config through it. The other modules take their context and the JdbcDataSourceModule as parameters.
• Consumers need KSP and a Kotlin 2.3+ compiler, because the runtime has Kotlin 2.4 metadata. Inara's first release may move to 2.5.

Not covered

The database modules' own tests still exercise only Kodein and Metro. The env, MySQL and PostgreSQL Inara flavors compile, but nothing runs them.