Add incremental ServiceContainer #45
Conversation
|
@copilot Try adding tests |
|
@AndreuCodina I've opened a new pull request, #46, to work on those changes. Once the pull request is ready, I'll request review from you. |
There was a problem hiding this comment.
Pull request overview
This PR introduces a new ServiceContainer abstraction to make service registration + resolution more ergonomic (auto-building/auto-initializing a ServiceProvider) and enables incremental descriptor updates after initialization, with corresponding updates across engine internals, tests, docs, and CI.
Changes:
- Add
ServiceContainerwith async resolve helpers, scope creation, and override helpers. - Make
ServiceProvider/CallSiteFactorysupport incremental descriptor additions via pending descriptors + incremental population. - Update docs/quickstart + API reference, and switch GitHub Actions installs to
uv sync.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/test_service_provider.py | Removes the “must be fully initialized before create_scope” expectation. |
| tests/test_service_container.py | Adds comprehensive tests for ServiceContainer auto-init, incremental adds, overrides. |
| src/wirio/service_provider_engine_scope.py | Ensures root provider initialization when entering a scope. |
| src/wirio/service_provider.py | Adds pending descriptor pipeline + incremental initialization hooks. |
| src/wirio/service_container.py | Introduces ServiceContainer wrapper over ServiceCollection. |
| src/wirio/service_collection.py | Stops caching a built ServiceProvider on the collection itself. |
| src/wirio/integrations/_fastapi_dependency_injection.py | Minor comment update around provider building in lifespan. |
| src/wirio/exceptions.py | Adds ServiceContainerNotBuiltError. |
| src/wirio/_service_lookup/_call_site_factory.py | Supports incremental descriptor population via add_descriptor(). |
| docs/pages/getting-started/quickstart.md | Updates quickstart to use ServiceContainer + new usage patterns. |
| docs/pages/core-concepts/*.md | Minor formatting edits; one section now potentially inconsistent with new container approach. |
| docs/pages/api-reference/service-container.md | Adds API reference page for ServiceContainer. |
| docs/mkdocs.yml | Adds ServiceContainer to MkDocs nav. |
| docs/code/getting_started/quickstart/fastapi_full_code.py | Updates example to use ServiceContainer. |
| .github/workflows/pull_request.yaml | Switches dependency install to uv sync --locked --all-extras. |
| .github/workflows/_test.yaml | Switches dependency install steps to uv sync. |
Comments suppressed due to low confidence (1)
docs/pages/core-concepts/pluggable-architecture.md:99
- This section states that Wirio intentionally avoids a “container-class API” and that the provider is sealed/immutable after
build_service_provider(). With the introduction ofServiceContainerand incremental descriptor support, this rationale appears outdated and potentially misleading for readers. Consider updating this section to clarify the newServiceContainerAPI (and whether late registration is now supported/encouraged) or adjust the claims about immutability/sealing accordingly.
Other libraries embrace a container-class API: we extend a `Container`, override methods, or mutate attributes to register services. That style works, but it comes with trade-offs that Wirio intentionally avoids:
- **Interoperability:** Both approaches technically work across frameworks, but the collection style keeps things primitive (just create an instance and start registering). Container subclasses introduce class-level state, overridden hooks, and metaclass magic that become friction points when we try to share the same container between, say, a CLI bootstrapper and an async worker, or application code and test cases.
- **Composability:** Collection-first helpers (`add_logging`, `add_sqlmodel`, etc.) compose like ordinary functions. Container subclasses tend to accumulate registration logic across inheritance hierarchies, making it harder to cherry-pick modules or share them between apps.
- **Predictability:** Once `build_service_provider()` runs, the provider is sealed. Container-class APIs often allow late mutation or rely on attribute access magic, which can hide ordering bugs.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 27 out of 27 changed files in this pull request and generated 9 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 27 out of 27 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
No description provided.