How should you (de-)compose multiple module dependencies

[strangemonad]

First, thanks for this great library!

All of the examples show a single, top-level Container instance that you configure dependencies on. This is fine for small (and possibly even medium apps) but at some point, it's convenient to have re-usable dependency bindings e.g. an API client package might have the common bindings for real vs fake client implementations.

In Guice you'd do this with a Module and binder.install(otherModule). Similar in Dagger.

This may be related to #200

[strangemonad]

After reading the source code a little bit more, I was hoping I'd be able to create some sort of utility function to compose multiple containers e.g.

package_a/container.py

container = Container()
# ...

package_b/container.py

container = Container()
# ...

main.py

container = Container()
compose(container, package_a.container.container, package_b.container.container

But it's not obvious how to directly do this as a helper function without depending on the Container._parent protected field.

Another alternative would be to rely on a convention of having a configure(container:Container) function e.g.

package_a/config.py

def configure(container): ...
# ...

package_b/config.py

def configure(container): ...
# ...

main.py

container = Container()
package_a.config.configure(container)
package_b.config.configure(container)

A non Guice / Java example of a DI framework that provides this sort of modular configuration is python-inject https://github.com/ivankorobkov/python-inject?tab=readme-ov-file#composable-configurations

[meadsteve]

@strangemonad this is a really good question. I've not actually considered (de)composition of lagom in this way.

How I've approach managing complexity is having separate containers for separate packages that extend a base container.

So something like:

# core/dependencies.py
base_dependency_container = Container()

base_dependency_container[Logger] = LogStuffClass
base_dependency_container[HttpClient] = SomeBaseHttpClient

#package_a/dependencies.py
container = Container(base_dependency_container)

container[SomeSpecialAThing] = lambda c: SomeSpecialAThing(c[HttpClient])

#package_b/dependencies.py
container = Container(base_dependency_container)

container[SomethingForB] = lambda c: SomethingForB(c[LogStuffClass])

Would this work for your use case? Otherwise we could definitely look at building a function to compose containers together. Although some thought would need to be given about what happens if two containers both define the same class.

[meadsteve]

(this is exactly what I need to document #200 )

[strangemonad]

@meadsteve not really. If anything I'd say this is probably the opposite of how I'd expect to compose larger applications coming from other languages with established DI frameworks. You usually want the bindings to be driven by the top-level app where everything comes together. Optionally, you might optionally specify that intermediate packages are going to required some dependency to be provided but not bind it.

e.g.

app_container
|__ installs package_a_container
      |__ depends on HttpClient (provided elsewhere)
      |__ binds SomeSpecialAThing
|__ installs package_b_container
     |__ depends on logging (provided elsewhere)
     |__ binds SomethingForB
|__ installs logging_package
     |_ binds Logger
|__ installs http_package
     |__ binds HttpClient

Basically, you end up wanting inversion of control all the way up. A few problems with making package_a and package_b depend directly on base_dependency_container is that they're both hard-coded dependencies. This has all of the same issues that prompted IoC in the first place

• If you don't control or can't change one of the packages you're stuck
• If you want to use package_a in 2 different apps that have different logging and http requirements (e.g. once on a server, another on a desktop or notebook client I might want a human friendly log format with a longer http client timeout and different auth configuration)
• When overriding bindings for tests
• ...