Container-local factories

[aedify-swi]

Hej there!

We're using the litestar web framework. It comes with it's own DI system, which is not as ergonomic as svcs. One thing it can do though and which we are using extensively, is injecting dependencies on a per request basis. So something like adding an ephemeral dependency on the container, just for the request.

Maybe something like this:

with svcs.Container(reg) as con:
    con.override_value(Request, current_request)
    my_repo = con.get(MyRepo) # uses injected Connection which itself depends on Request

Example use case with postgres/psycopg:

An HttpRequest has a "tenant_id" header value. That value gets passed into a factory that makes a TenantConnection from a Connection and sets some properties (e.g. calls a "SET tenant = :id"). Now all repos/services that require an injected Connection, use the TenantConection and the DB can do some additional checks on each SQL query. This works in litestar, because the Request is automatically available as a dependency for all downstream dependencies.

I hope my example is clear enough.

@hynek, what do you think of this? Could this be a feature you'd be willing to support?

[hynek]

Isn't that something that could be solved with nested services?

If a factory takes an argument named svcs_container or any name that is typed as svcs.Container, it gets the current container passed.

So you can do something like:

def tf(svcs_container) -> TenantConnection:
    req = svcs_container.get(Request)
    con = svcs_container.get(Connection)
    con.execute(text("SET tenant = :id", {"id": req.tenant_id}))

    return con

If svcs_container.get(Request) is a problem, this might be an argument for allowing to pass kwargs into factories.

[aedify-swi]

Maybe it is just my misunderstanding of the different life cycles. In my head the registry should not be updated for every new request I get. But of course I could also just use registry.register_value(Request, current_request) in a middleware-thing and go on from there.

[hynek]

No, you're 100% right. You shouldn't be modifying Registry on every request, that would inevitably lead to some weird side-effects. I wasn't sure if you can get the request from thin air like in Flask.

I guess it makes sense to have an additional Container-local scope/registry.

I've had a very similar problem like yours but I've moved the extraction of the thing I need to SET into the view and then passed it into my UnitOfWork as a required argument to start a transaction. I guess I could move the extraction into a factory and instantiate the UnitOfWork with it straight away.

---

I guess the API would be add an additional register_factory/register_value pair to Container and the used Registry is:

1. Checked first to find a factory, and
2. automatically closed at the end of the Container life cycle.
3. I think we should call them differently to avoid confusion? Something like container.register_local_factory(...)?

---

Pinging also @elfjes who had dreams and opinions about more scopes. :)

[aedify-swi]

That would fit my current use case very well. As for other scopes, maybe a new context manager container.local_scope() to open a new sub-scope from the current scope, would be a good addition? But that is just an idea, I really don't have a use-case for this. 🤷

[RonnyPfannschmidt]

this is also similar to pytest scopes, and something i'm interested in (pytest fixtures have certain needs)

[hynek]

The original problem has now been implemented in #56.

I still plan on chaining registries and containers, but it's a bit of a separate problem because those, while more flexible, require to replace the container which is not always possible. Therefore I consider those two problems orthogonal.