Chained/Cloned containers

[jamie-at-arkifi]

Per fedi, https://tacobelllabs.net/@astraluma/111904242641573392

I think it would be useful to have chained/cloned/inherited containers: basically, being able to have a container access the instances of another container without taking over it's cleanup.

This would allow more flexibility in using svcs in a way that reflects the lifecycle structure of the application. By which I mean, many applications have several lifecycles/scopes, and it would be good to have more options for integrating DI/IoC into that.

• A web app might have the app scope (eg config, database connection pool) and the request/job scope (eg, a specific db transaction, the current user)
• pytest has many nested scopes, reflecting the structure of the test suite

Basically, more scopes more good?

These could also replace singleton factories or registry-based value, since instead you could have a global root container, and could be a way to handle #26.

[jamie-at-arkifi]

I also like this for advanced features, like reloading settings by clearing/reloading values in the App-bound container.

[hynek]

I’ve been thinking about this quite a bit and if I read you correctly, the best, yet nontrivial move, would be to move away from registries as a first-class concept to containers all the way?

IOW the moment svcs is initialized, it creates its first root container that is then passed into the app/web integrations. This container could carry system-wide dependencies like configs or engines (fixing #34) and each request would create a child container with the lifetime of the request.

The full cache of a container could be a ChainMap of all parents’s caches and if the service is missing, it’s added to the local one.

When a parent container is closed, it also closes all of its child containers.

Child containers therefore need to know both about their parents for cache lookups and their children for cleanups.

I think, it would also make testing easier, since you can clone the real container and overwrite just the factory you want to change. No need to flush upstream caches.

Open questions

• it would be necessary to create certain services in the root container, otherwise your app ends up with countless Engines and load configuration on ever request. What is an unconfusing API for that?
• relatedly: is there a need for a special-cased root container?
• should it be possible to circumvent a parent’s service cache? Maybe inherit=True argument to register_factory?

I think this whole proposal is basically what @elfjes has been asking for from day 1? /o\

[hynek]

Side-note: going down this route will make it necessary to deal with race conditions, I'm afraid.

I think the safest way would be to store lock_s_ (one threading, one asyncio) on the root container since a child can go away but a parent cannot. As I write this it occurs to me that this also means that the lock can be passed into child containers.

[tuukkamustonen]

So is the idea that there is:

• There's one registry
• Nested containers

What if I call child.get(str):

1. If parent.get(str) was called beforehand, it would retrieve the value stored in the parent container?
2. If if it wasn't, then a new value would be instantiated and stored to the child container?
   • If after this I would call parent.get(str) would it instantiate a new value into parent container?

Pretty obvious (I guess) that register_local_value() would register a container-local value. But let's forget about that, what if you only use the usual Registry.register_factory as above, what would happen?

[hynek]

I mean that's exactly how scopes work, no? If you create a child, it means that:

1. you want to share something with the parent container (otherwise you could just create another unrelated container)
2. you want the new scope cleaned separately

Your example is good, because depending on whether or not the parent creates + caches a value, the child will reuse or create/cleanup which sounds weird – but exactly how scoping would work? And exactly what you'd want if you, for example have an http pool/database connection that is supposed to be used throughout a request and then build on that in smaller scopes?

If they wouldn't share the cache, what would be the point except inheriting local factories? Is there some authoritative prior art we could orient ourselves at?

[tuukkamustonen]

Yeah, just thought it would be confusing if there's no predefined way to know at what "level" the value was instantiated(?) That's why my previous example showed two different registries.

Wouldn't registering "local" values go away with inheritable containers? Ie. if you need an override, create a nested container and instead?

Maybe it would be best think this through an example use case. My assumption was that this could be used in web apps like:

def some_endpoint(svcs: Container):
    request = svcs.get(Request)

But then, for that example it would be a bit silly because Request is nothing to lazy load / cache, instead better just inject it and pass along:

def some_endpoint(request: Request):
    pass_it_somewhere_that_needs_it(request)

So... uh, what would be a good use case?

[hynek]

Wouldn't registering "local" values go away with inheritable containers? Ie. if you need an override, create a nested container and instead?

Yes, but only if you don't inherit the cache – otherwise the behavior is different. 🤔

I mean FWIW, this could totally be an option: parent.create_child(inherit_cache=False). We can even make it mandatory to avoid confusion while reading.

---

I 100% agree with collecting use-cases.

Jamie specifically said she'd like "being able to have a container access the instances of another container without taking over it's cleanup." which would be literally the inherit_cache=True case.

We've all talked about "more scopes" in abstract, but there's not much concrete examples, except that register_local is indeed a scope that really wants out. :)

There's also:

A web app might have the app scope (eg config, database connection pool) and the request/job scope (eg, a specific db transaction, the current user)

Which makes sense: currently I create the pool by hand and register a registry close hook:

def make_app():
    ...
    engine = db.engine_from_url(app_cfg.sqlany_url)
    ping = text("SELECT 1")
    svcs.flask.register_factory(
        app,
        Connection,
        engine.connect,
        on_registry_close=engine.dispose,
        ping=lambda conn: conn.execute(ping),
    )

    @atexit
    def cleanup():
        svcs.flask.close_registry()

This too, is a scope that wants out.

I'm thinking something like:

def make_app():
    reg = svcs.Registry()

    reg.register_factory(
        app, Engine, lambda: db.engine_from_url(app_cfg.sqlany_url),
        eager=True  # create + cache immediately on container creation
    )

    # Now this is a bit tricky. One way is to define a lazy (= default)
    # factory. This has the downside of possible accidental caching of
    # a connection.
    reg.register_factory(
        Connection,
        lambda svcs_container: svcs_container.get(Engine).connect,
        ping=lambda conn: conn.execute(ping),
    )

    app_container = Container(reg)

    # Alternative: if we want scopes, we still need to be able to scope
    # factories, too?? Although it's still possible to accidentally ask
    # for a connection too early; optimal would be to define the factory
    # on the request container.
    app_container.register_local_factory(
        Connection,
        lambda svcs_container: svcs_container.get(Engine).connect,
        ping=lambda conn: conn.execute(ping),
    )

    # svcs.flask.get(X) would effectively become app_container.create_child(inherit_cache=True).get(X)
    svcs.flask.set_app_container(app_container)

    @atexit
    def cleanup():
        svcs.flask.close_registry() # closes all containers

Thoughts @jamie-at-arkifi @tuukkamustonen @pauleveritt @proofit404 @elfjes?

[pauleveritt]

We've all talked about "more scopes" in abstract, but there's not much concrete examples, except that register_local is indeed a scope that really wants out. :)

I have an example but I don't know if that comment was more like "please, PLEASE, no concrete examples." 😀

[hynek]

Naw, we‘re collecting use-cases to see if potential designs can work out. :)

[pauleveritt]

I have a system built around rendering components and subcomponents. I want a root registry for all the system registrations, then a per-request registry, as described here.

A view renders a component and for a while I wanted per-component registrations. Not having it was a little painful. Of course components have subcomponents.

These component/subcomponent registries would be really lightweight. They would hold very little and get most of their registrations and data from the root and request registries. They would override very little, but the "little" they override would be important.