Dataclasses and "declarative DI": Leave as docs, consider it an extra, or ???

[pauleveritt]

I wrote a tutorial in which I constructed a DI system based on dataclasses and sniffing at type annotations to inject things. I think it's valuable in two respects:

• Reading how it was built from scratch can encourage people to come up with their own patterns atop wired

• I like that DI system and want to promote it

For the latter, I could of course just leave it as a sample app. We could, though, consider it software (once it is done of course.) Choices:

• I make a repo for wired.di or wired.dcdi

• We make src/wired/addons/dcdi.py to mark it as "not wired" but kinda part of wired" :grin:

• We just say src/wired/dcdi.py

Obviously this is all still experimentation, on a branch or fork, etc.

[mmerickel]

I'm very interested in wired.dataclasses or wired.ext.dataclasses or something with support for automatically creating factories for dataclass objects. I don't see a need at this point to put it in a separate package from wired anyway.

[pauleveritt]

I'll let you decide whether you want "ext" in there. I think it's worth promoting that wired is tiny and there are optional things, so maybe ext has some merit.

For now, not a rush. I'll stick to doing this as a second tutorial.

[mmerickel]

Let's go with wired.dataclasses for now if that makes sense to you. I'm thinking of it as patterns / functions / helpers for doing stuff with dataclasses to hook into wired. If that's not how you see it let me know.

[pauleveritt]

I'm fine with that. But FTR I view it as DI first and dataclasses second. wired advertises itself as a foundation for building a DI system. The thing I'm thinking about is one such DI system.

In fact, parts of it might not be dataclasses. There might be standalone functions, or class methods, that have their arguments sniffed and injected-on-call.

[mmerickel]

From what I've seen to this point, the dataclass bindings you've written are pretty well dependent on dataclass apis for introspecting the objects. Similarly attrs has its own way of pulling out metadata from properties. It seems at least at that level it needs to be per-library to find a way to auto-generate factories.

If you are talking about higher level stuff combining objects from different libraries my thought is that's done just via lookup of factories by type (container.get(Foo)) where no one really cares whether Foo is a dataclass or attrs object or anything else.

[pauleveritt]

Agreed, well said. Dataclasses it is.

[pauleveritt]

Let's close this ticket. I believe you've agreed to make it a part of the package.