Pass around a config-time container

[pauleveritt]

My (Paul's) samples have a pattern of making a container during config-time (bootstrap) and re-using it for each thing done during bootstrap. Including, passing the container to "add-ons."

This is challenging though. wired doesn't have a concept of add-ons with contracts ("Put an includeme at the top level and we'll pass you a config.) A wired app might not have a bootstrap phase at all, or might have a different idea of bootstrap.

Also, the "pluggable app" model kind of means:

• Use wired as "the System" to...
• Write a custom App, instead of re-using Flask/Pyramid/whatever, which has...
• Custom Addons to the App, using an extension system, and
• Configuration by the Site which wires it all together

But that's our world view and others might not want it. OTOH, we should support people that choose to go that route, as we can provide jargon, code, an extension system, perhaps as a wired extension (wired.plugins.) In that model, "config-time container" might actually be multiple containers, each for a phase of the configuration (core, add-ons, etc.) to provide some ordering.

[mmerickel]

Wired as it stands is lower level than something like Pyramid's configurator. Wired provides only a registry and containers. A configurator is one potential system for configuring the registry and there are probably several different competing approaches on how to build the registry. My main position is that logic probably doesn't belong in the registry object itself, but it could still belong in wired in some way.

from wired.configurator import Configurator

config = Configurator()
config.include('myaddon')
registry = config.make_registry()
...
container = registry.create_container()

Any sort of builder pattern would be a viable candidate so long as it pops out a "built" registry. Maybe something with decorators, or entry points, or includeme functions. I'm definitely open to options there so long as they result in factory functions in the registry.

[pauleveritt]

Completely agree. I think binding into other systems (e.g. what pyramid_services is doing) should be a goal.

I agree that we shouldn't ship a configuration system. But if you want factories to all be registered in the same container, then this ticket is worth discussing.

But if it doesn't really matter if different parts of bootstrap use different containers, then it's not needed.

Though I'll wonder how to portray the purpose of a container. :smile:

[mmerickel]

Yeah for sure, I agree with all of that. In the specific situation of pyramid_services, I currently integrate a registry defined elsewhere into my pyramid app using config.set_service_registry(registry) and then any usage of config.register_service_factory will get assigned to that registry. That's cool because you can then bind the registry into another system like that, but there are some real benefits to having wired ship an optional builder / config system as well.

Going back to the config-time container since that was your original issue, I'll point out that Pyramid defines a config-time contract versus a runtime-contract and that's defined by the Configurator. For example, if you want the settings at config-time you can use config.get_settings() whereas at runtime everyone would use registry.settings probably via request.registry.settinsg. A similar argument could be made here that passing around some config-time data could be done in this way and that passing around a container built from a partially-constructed registry may be a bit wonky.

[pauleveritt]

The wonky part is right. I've hit that a few times.

On the basic question...is there any logical/physical reason to group a set of actions (e.g. bootstrap) in the same container? Or am I mis-applying concepts of "transaction" and maybe "subrequest" where it isn't warranted?

[mmerickel]

I'd probably argue that containers aren't a config-time concept. As far as when to create a container, it should usually be for a logical operation (imo) such as a web request, or a background job. In scripts where I want to do some batch processing I'll make a container per thread per job. I definitely approach it as "per transaction" myself to keep it simple. I'm sure other people have other feelings on that, but that approach has worked really well for me because my brain works on ACID.

[pauleveritt]

I suggest we close this one.

[mmerickel]

Sounds good!