dependency-injection-pattern 0.0.5__tar.gz → 0.0.7__tar.gz

{dependency_injection_pattern-0.0.5/src/dependency_injection_pattern.egg-info → dependency_injection_pattern-0.0.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dependency-injection-pattern
-Version: 0.0.5
+Version: 0.0.7
 Summary: Python implementation of the Dependency Injection pattern.
 Author-email: Anders Madsen <anders.madsen@alphavue.com>
 License-Expression: MIT
@@ -18,15 +18,16 @@ Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
 Classifier: Programming Language :: Python
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Topic :: Software Development :: Libraries
 Classifier: Typing :: Typed
-Requires-Python: >=3.10
+Requires-Python: <3.15,>=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: typing-utilities<0.2,>=0.1.0
-Requires-Dist: runtime-reflection-lite<0.2,>=0.1.2
+Requires-Dist: runtime-reflection-lite<0.3,>=0.2.0
 Provides-Extra: test
 Requires-Dist: pytest>=8.3; extra == "test"
 Requires-Dist: pytest-cov>=6.1; extra == "test"
@@ -39,22 +40,133 @@ Dynamic: license-file
 ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/dependency-injection-pattern)
 [![PyPI Downloads](https://static.pepy.tech/badge/dependency-injection-pattern/week)](https://pepy.tech/projects/dependency-injection-pattern)
 
-# dependency-injection-pattern
-> A Python implementation of the Dependency Injection pattern.
+# Dependency Injection Pattern (Python)
 
-This project extends python with a real dependency injection or Inversion of Control (IoC) implementation, relying on typing and inspection to achieve a seamless injection of dependencies.
+A typed dependency injection framework for Python — focused on clarity, structure, and maintainability.
 
-Though not normally associated with Python applications, dependency injection can greatly reduce time spent during development and testing. Usually, in a longrunning Python application or service, you would put the container registration inside the `__main_.py` file and similar code in test files, where service implementations can easily be substituted.
+## 🚀 Why this exists
 
-## How it works
-When a service is requested, the provider looks it up in the factory dictionary, which then gets or creates a fitting instance. Any parameters needed for instantiation is supplied (injected) by the provider.
+As Python applications grow, managing dependencies becomes increasingly difficult:
 
-A service implementation may be inferred by a service in which case the service constructor is used, and correspondingly a service may be inferred by the return type of an implementation function.
+- Hidden dependencies make systems harder to understand
+- Tight coupling reduces flexibility
+- Testing requires complex setup and mocking
+- Structure becomes inconsistent across modules
 
-## Conventions
-- All dependencies are resolved when container is sealed, which implements a fail-fast pattern. Only exceptions are optional dependencies or dependencies with a default value.
+Unlike many other ecosystems, Python lacks a widely adopted, structured approach to dependency injection.
+
+👉 This project aims to introduce **clear, typed dependency management** to Python applications.
+
+
+## ✨ Features
+
+- 🧩 Strongly typed dependency injection
+- 🧠 Explicit dependency definitions
+- 🔄 Clear separation of concerns
+- 🧪 Improved testability
+- 🏗 Support for structured application architecture
+- ⚡ Lightweight and Python-native design
+
+
+## 📦 Use cases
+
+This library is particularly useful when building:
+
+- Backend services
+- Data engineering workflows
+- ETL pipelines
+- Modular applications
+- Systems with complex dependency graphs
+
+👉 Especially valuable in projects where maintainability and scalability matter.
+
+
+## 🏗 Design philosophy
+
+This project is built around a few key principles:
+
+### 1. Explicit over implicit
+Dependencies should be visible and well-defined — not hidden in implementation details.
+
+### 2. Type-driven structure
+Type hints are used as a foundation for defining and resolving dependencies.
+
+### 3. Maintainability over convenience
+The goal is not to reduce lines of code — but to make systems easier to evolve.
+
+### 4. Minimal abstraction
+The framework avoids unnecessary complexity and stays close to Python’s core concepts.
+
+
+## 🔗 What this enables
+
+By introducing structured dependency injection, you get:
+
+- Clear boundaries between components
+- Easier reasoning about system design
+- More predictable runtime behavior
+- Improved ability to refactor safely
+
+👉 This is especially powerful in larger systems where complexity grows over time.
+
+
+## ⚖️ Trade-offs
+
+| Focus ✅ | Not a goal ❌ |
+|---------|--------------|
+| Structured architecture | Magic-based auto-wiring |
+| Type safety | Implicit dependency resolution |
+| Clarity and control | Minimal configuration at all costs |
+
+👉 This library prioritizes **explicit design over automation**.
+
+
+## 🧠 Inspiration
+
+Inspired by dependency injection patterns from ecosystems such as:
+
+- C# / .NET (built-in DI container)
+- Java (Spring, Guice)
+
+But intentionally adapted to fit Python’s dynamic nature
+without introducing heavy frameworks or unnecessary indirection.
+
+
+## 🎯 When to use
+
+Use this library if you:
+
+- Are building medium to large Python applications
+- Want clearer separation between components
+- Need better testability
+- Prefer structured architecture over ad-hoc patterns
+
+
+## 🚫 When not to use
+
+This library may be unnecessary if:
+
+- Your project is small or short-lived
+- Dependency complexity is minimal
+- Simplicity is more important than structure
+
+
+## 🔗 Related projects
+
+Part of a broader focus on:
+
+- Clean architecture
+- Runtime abstractions
+- Developer tooling in Python
+
+👉 https://github.com/apmadsen
+
+
+
+## 🤝 Contributing
+
+Feedback, ideas, and contributions are welcome!
 
-- Singleton services may not depend on scoped or transient services, as this would negate the "transient" or "scoped" part since a singleton service would keep a reference to it's dependencies indefinitely.
 
 ## Example:
 

dependency_injection_pattern-0.0.7/README.md

@@ -0,0 +1,182 @@
+[![Test](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test.yml/badge.svg)](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test.yml)
+[![Coverage](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test-coverage.yml/badge.svg)](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test-coverage.yml)
+[![Stable Version](https://img.shields.io/pypi/v/dependency-injection-pattern?label=stable&sort=semver&color=blue)](https://github.com/apmadsen/dependency-injection-pattern/releases)
+![Pre-release Version](https://img.shields.io/github/v/release/apmadsen/dependency-injection-pattern?label=pre-release&include_prereleases&sort=semver&color=blue)
+![PyPI - Python Version](https://img.shields.io/pypi/pyversions/dependency-injection-pattern)
+[![PyPI Downloads](https://static.pepy.tech/badge/dependency-injection-pattern/week)](https://pepy.tech/projects/dependency-injection-pattern)
+
+# Dependency Injection Pattern (Python)
+
+A typed dependency injection framework for Python — focused on clarity, structure, and maintainability.
+
+## 🚀 Why this exists
+
+As Python applications grow, managing dependencies becomes increasingly difficult:
+
+- Hidden dependencies make systems harder to understand
+- Tight coupling reduces flexibility
+- Testing requires complex setup and mocking
+- Structure becomes inconsistent across modules
+
+Unlike many other ecosystems, Python lacks a widely adopted, structured approach to dependency injection.
+
+👉 This project aims to introduce **clear, typed dependency management** to Python applications.
+
+
+## ✨ Features
+
+- 🧩 Strongly typed dependency injection
+- 🧠 Explicit dependency definitions
+- 🔄 Clear separation of concerns
+- 🧪 Improved testability
+- 🏗 Support for structured application architecture
+- ⚡ Lightweight and Python-native design
+
+
+## 📦 Use cases
+
+This library is particularly useful when building:
+
+- Backend services
+- Data engineering workflows
+- ETL pipelines
+- Modular applications
+- Systems with complex dependency graphs
+
+👉 Especially valuable in projects where maintainability and scalability matter.
+
+
+## 🏗 Design philosophy
+
+This project is built around a few key principles:
+
+### 1. Explicit over implicit
+Dependencies should be visible and well-defined — not hidden in implementation details.
+
+### 2. Type-driven structure
+Type hints are used as a foundation for defining and resolving dependencies.
+
+### 3. Maintainability over convenience
+The goal is not to reduce lines of code — but to make systems easier to evolve.
+
+### 4. Minimal abstraction
+The framework avoids unnecessary complexity and stays close to Python’s core concepts.
+
+
+## 🔗 What this enables
+
+By introducing structured dependency injection, you get:
+
+- Clear boundaries between components
+- Easier reasoning about system design
+- More predictable runtime behavior
+- Improved ability to refactor safely
+
+👉 This is especially powerful in larger systems where complexity grows over time.
+
+
+## ⚖️ Trade-offs
+
+| Focus ✅ | Not a goal ❌ |
+|---------|--------------|
+| Structured architecture | Magic-based auto-wiring |
+| Type safety | Implicit dependency resolution |
+| Clarity and control | Minimal configuration at all costs |
+
+👉 This library prioritizes **explicit design over automation**.
+
+
+## 🧠 Inspiration
+
+Inspired by dependency injection patterns from ecosystems such as:
+
+- C# / .NET (built-in DI container)
+- Java (Spring, Guice)
+
+But intentionally adapted to fit Python’s dynamic nature
+without introducing heavy frameworks or unnecessary indirection.
+
+
+## 🎯 When to use
+
+Use this library if you:
+
+- Are building medium to large Python applications
+- Want clearer separation between components
+- Need better testability
+- Prefer structured architecture over ad-hoc patterns
+
+
+## 🚫 When not to use
+
+This library may be unnecessary if:
+
+- Your project is small or short-lived
+- Dependency complexity is minimal
+- Simplicity is more important than structure
+
+
+## 🔗 Related projects
+
+Part of a broader focus on:
+
+- Clean architecture
+- Runtime abstractions
+- Developer tooling in Python
+
+👉 https://github.com/apmadsen
+
+
+
+## 🤝 Contributing
+
+Feedback, ideas, and contributions are welcome!
+
+
+## Example:
+
+```python
+from logging import Logger
+from di import Container
+
+def get_logger() -> Logger:
+    return Logger("app")
+
+class Service1:
+    def get_value(self) -> str:
+        return "Some value"
+
+class Service2:
+    def __init__(self, service1: Service1, log: Logger):
+        self.service1 = service1
+        self.log = log
+
+    def get_value(self) -> str:
+        self.log.debug("Someone requested value...")
+        return f"Service1 returned: {self.service1.get_value()}"
+
+class Application:
+    def __init__(self, service2: Service2, log: Logger):
+        self.service2 = service2
+        log.info("Application starting")
+
+    def get_value(self) -> str:
+        return f"Service2 returned: {self.service2.get_value()}"
+
+
+container = Container()
+container.add_singleton(get_logger)
+container.add_transient(Service1)
+container.add_transient(Service2)
+container.add_transient(Application)
+
+provider = container.provider() # container is sealed beyond this point
+
+app = provider.provide(Application)
+
+value = app.get_value() # => "Service2 returned: Service1 returned: Some value"
+```
+
+## Full documentation
+
+[Go to documentation](https://github.com/apmadsen/dependency-injection-pattern/blob/main/docs/documentation.md)

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7}/pyproject.toml

@@ -22,6 +22,7 @@ classifiers = [
     "Programming Language :: Python :: 3.11",
     "Programming Language :: Python :: 3.12",
     "Programming Language :: Python :: 3.13",
+    "Programming Language :: Python :: 3.14",
     "Programming Language :: Python",
     "Topic :: Software Development :: Libraries :: Python Modules",
     "Topic :: Software Development :: Libraries",
@@ -29,9 +30,9 @@ classifiers = [
 ]
 dependencies = [
     "typing-utilities >= 0.1.0, < 0.2",
-    "runtime-reflection-lite >= 0.1.2, < 0.2"
+    "runtime-reflection-lite >= 0.2.0, < 0.3"
 ]
-requires-python = ">=3.10"
+requires-python = ">= 3.10, < 3.15"
 
 [project.urls]
 repository = "https://github.com/apmadsen/dependency-injection-pattern"

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7/src/dependency_injection_pattern.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dependency-injection-pattern
-Version: 0.0.5
+Version: 0.0.7
 Summary: Python implementation of the Dependency Injection pattern.
 Author-email: Anders Madsen <anders.madsen@alphavue.com>
 License-Expression: MIT
@@ -18,15 +18,16 @@ Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
 Classifier: Programming Language :: Python
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Topic :: Software Development :: Libraries
 Classifier: Typing :: Typed
-Requires-Python: >=3.10
+Requires-Python: <3.15,>=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: typing-utilities<0.2,>=0.1.0
-Requires-Dist: runtime-reflection-lite<0.2,>=0.1.2
+Requires-Dist: runtime-reflection-lite<0.3,>=0.2.0
 Provides-Extra: test
 Requires-Dist: pytest>=8.3; extra == "test"
 Requires-Dist: pytest-cov>=6.1; extra == "test"
@@ -39,22 +40,133 @@ Dynamic: license-file
 ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/dependency-injection-pattern)
 [![PyPI Downloads](https://static.pepy.tech/badge/dependency-injection-pattern/week)](https://pepy.tech/projects/dependency-injection-pattern)
 
-# dependency-injection-pattern
-> A Python implementation of the Dependency Injection pattern.
+# Dependency Injection Pattern (Python)
 
-This project extends python with a real dependency injection or Inversion of Control (IoC) implementation, relying on typing and inspection to achieve a seamless injection of dependencies.
+A typed dependency injection framework for Python — focused on clarity, structure, and maintainability.
 
-Though not normally associated with Python applications, dependency injection can greatly reduce time spent during development and testing. Usually, in a longrunning Python application or service, you would put the container registration inside the `__main_.py` file and similar code in test files, where service implementations can easily be substituted.
+## 🚀 Why this exists
 
-## How it works
-When a service is requested, the provider looks it up in the factory dictionary, which then gets or creates a fitting instance. Any parameters needed for instantiation is supplied (injected) by the provider.
+As Python applications grow, managing dependencies becomes increasingly difficult:
 
-A service implementation may be inferred by a service in which case the service constructor is used, and correspondingly a service may be inferred by the return type of an implementation function.
+- Hidden dependencies make systems harder to understand
+- Tight coupling reduces flexibility
+- Testing requires complex setup and mocking
+- Structure becomes inconsistent across modules
 
-## Conventions
-- All dependencies are resolved when container is sealed, which implements a fail-fast pattern. Only exceptions are optional dependencies or dependencies with a default value.
+Unlike many other ecosystems, Python lacks a widely adopted, structured approach to dependency injection.
+
+👉 This project aims to introduce **clear, typed dependency management** to Python applications.
+
+
+## ✨ Features
+
+- 🧩 Strongly typed dependency injection
+- 🧠 Explicit dependency definitions
+- 🔄 Clear separation of concerns
+- 🧪 Improved testability
+- 🏗 Support for structured application architecture
+- ⚡ Lightweight and Python-native design
+
+
+## 📦 Use cases
+
+This library is particularly useful when building:
+
+- Backend services
+- Data engineering workflows
+- ETL pipelines
+- Modular applications
+- Systems with complex dependency graphs
+
+👉 Especially valuable in projects where maintainability and scalability matter.
+
+
+## 🏗 Design philosophy
+
+This project is built around a few key principles:
+
+### 1. Explicit over implicit
+Dependencies should be visible and well-defined — not hidden in implementation details.
+
+### 2. Type-driven structure
+Type hints are used as a foundation for defining and resolving dependencies.
+
+### 3. Maintainability over convenience
+The goal is not to reduce lines of code — but to make systems easier to evolve.
+
+### 4. Minimal abstraction
+The framework avoids unnecessary complexity and stays close to Python’s core concepts.
+
+
+## 🔗 What this enables
+
+By introducing structured dependency injection, you get:
+
+- Clear boundaries between components
+- Easier reasoning about system design
+- More predictable runtime behavior
+- Improved ability to refactor safely
+
+👉 This is especially powerful in larger systems where complexity grows over time.
+
+
+## ⚖️ Trade-offs
+
+| Focus ✅ | Not a goal ❌ |
+|---------|--------------|
+| Structured architecture | Magic-based auto-wiring |
+| Type safety | Implicit dependency resolution |
+| Clarity and control | Minimal configuration at all costs |
+
+👉 This library prioritizes **explicit design over automation**.
+
+
+## 🧠 Inspiration
+
+Inspired by dependency injection patterns from ecosystems such as:
+
+- C# / .NET (built-in DI container)
+- Java (Spring, Guice)
+
+But intentionally adapted to fit Python’s dynamic nature
+without introducing heavy frameworks or unnecessary indirection.
+
+
+## 🎯 When to use
+
+Use this library if you:
+
+- Are building medium to large Python applications
+- Want clearer separation between components
+- Need better testability
+- Prefer structured architecture over ad-hoc patterns
+
+
+## 🚫 When not to use
+
+This library may be unnecessary if:
+
+- Your project is small or short-lived
+- Dependency complexity is minimal
+- Simplicity is more important than structure
+
+
+## 🔗 Related projects
+
+Part of a broader focus on:
+
+- Clean architecture
+- Runtime abstractions
+- Developer tooling in Python
+
+👉 https://github.com/apmadsen
+
+
+
+## 🤝 Contributing
+
+Feedback, ideas, and contributions are welcome!
 
-- Singleton services may not depend on scoped or transient services, as this would negate the "transient" or "scoped" part since a singleton service would keep a reference to it's dependencies indefinitely.
 
 ## Example:
 

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7}/src/dependency_injection_pattern.egg-info/requires.txt

@@ -1,5 +1,5 @@
 typing-utilities<0.2,>=0.1.0
-runtime-reflection-lite<0.2,>=0.1.2
+runtime-reflection-lite<0.3,>=0.2.0
 
 [test]
 pytest>=8.3

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7}/src/di/core/container.py

@@ -1,6 +1,6 @@
 from __future__ import annotations
 from typing import TypeVar, Callable, Any, cast, overload, TYPE_CHECKING
-from typingutils import is_type, isinstance_typing, get_optional_type
+from typingutils import is_type, isinstance_typing, issubclass_typing, get_optional_type
 from types import FunctionType
 from weakref import ref
 from runtime.reflection.lite import get_signature
@@ -282,7 +282,13 @@ class Container:
         elif isinstance(service, type) and issubclass(service, Provider): # pyright: ignore[reportUnnecessaryIsInstance]
             return True
         elif is_type(service):
-            return service in self.__factories
+            if service in self.__factories:
+                return True
+            else:
+                # check for factories of derived types
+                for provided_service, _ in self.__factories.items():
+                    if issubclass_typing(provided_service, cast(type[Any], service)):
+                        return True
 
         return False
 
@@ -317,6 +323,15 @@ class Container:
                     factory = self.__factories[cast(type, svc)]
                     break
 
+        # check for factories of derived types
+        for svc in [svc_type, service]: # pyright: ignore[reportUnknownVariableType]
+            if is_type(svc):
+                for provided_service, provided_factory in self.__factories.items():
+                    if issubclass_typing(provided_service, cast(type[Any], svc)):
+                        factory = provided_factory
+                        break
+
+
         return factory, default, is_optional
 
     def _get(self, service: type[T] | ServiceRequest[T]) -> Factory[T] | T | None:

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7}/src/di/core/default_scope.py

@@ -42,7 +42,7 @@ class DefaultScope(Scope):
                     try:
                         if is_context(service):
                             LOG.debug(f"Disposing service '{get_service_name(service)}' on thread '{current_thread().name}'")
-                            getattr(implementation, "__exit__")()
+                            getattr(implementation, "__exit__")(None, None, None)
 
                     except Exception as ex: # pragma: no cover
                         # swallow exception, as it's caught in the finalizer thread

{dependency_injection_pattern-0.0.5 → dependency_injection_pattern-0.0.7}/tests/test_provider.py

@@ -134,3 +134,23 @@ def test_generic_service():
     provider.provide(GenericClass[str])
     provider.provide(GenericClass[int])
 
+
+
+def test_derived_service():
+    container = Container()
+    container.add_singleton(Service)
+    provider = container.provider()
+
+    # the container only has a factory for the Service class which
+    # is derived from the IService class, but subclass matching
+    # makes sure that both types can be provided
+
+    assert provider.provides(IService)
+    svc = provider.provide(IService)
+    assert isinstance(svc, IService)
+    assert isinstance(svc, Service)
+
+    assert provider.provides(Service)
+    svc = provider.provide(Service)
+    assert isinstance(svc, IService)
+    assert isinstance(svc, Service)

dependency_injection_pattern-0.0.5/README.md

@@ -1,71 +0,0 @@
-[![Test](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test.yml/badge.svg)](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test.yml)
-[![Coverage](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test-coverage.yml/badge.svg)](https://github.com/apmadsen/dependency-injection-pattern/actions/workflows/python-test-coverage.yml)
-[![Stable Version](https://img.shields.io/pypi/v/dependency-injection-pattern?label=stable&sort=semver&color=blue)](https://github.com/apmadsen/dependency-injection-pattern/releases)
-![Pre-release Version](https://img.shields.io/github/v/release/apmadsen/dependency-injection-pattern?label=pre-release&include_prereleases&sort=semver&color=blue)
-![PyPI - Python Version](https://img.shields.io/pypi/pyversions/dependency-injection-pattern)
-[![PyPI Downloads](https://static.pepy.tech/badge/dependency-injection-pattern/week)](https://pepy.tech/projects/dependency-injection-pattern)
-
-# dependency-injection-pattern
-> A Python implementation of the Dependency Injection pattern.
-
-This project extends python with a real dependency injection or Inversion of Control (IoC) implementation, relying on typing and inspection to achieve a seamless injection of dependencies.
-
-Though not normally associated with Python applications, dependency injection can greatly reduce time spent during development and testing. Usually, in a longrunning Python application or service, you would put the container registration inside the `__main_.py` file and similar code in test files, where service implementations can easily be substituted.
-
-## How it works
-When a service is requested, the provider looks it up in the factory dictionary, which then gets or creates a fitting instance. Any parameters needed for instantiation is supplied (injected) by the provider.
-
-A service implementation may be inferred by a service in which case the service constructor is used, and correspondingly a service may be inferred by the return type of an implementation function.
-
-## Conventions
-- All dependencies are resolved when container is sealed, which implements a fail-fast pattern. Only exceptions are optional dependencies or dependencies with a default value.
-
-- Singleton services may not depend on scoped or transient services, as this would negate the "transient" or "scoped" part since a singleton service would keep a reference to it's dependencies indefinitely.
-
-## Example:
-
-```python
-from logging import Logger
-from di import Container
-
-def get_logger() -> Logger:
-    return Logger("app")
-
-class Service1:
-    def get_value(self) -> str:
-        return "Some value"
-
-class Service2:
-    def __init__(self, service1: Service1, log: Logger):
-        self.service1 = service1
-        self.log = log
-
-    def get_value(self) -> str:
-        self.log.debug("Someone requested value...")
-        return f"Service1 returned: {self.service1.get_value()}"
-
-class Application:
-    def __init__(self, service2: Service2, log: Logger):
-        self.service2 = service2
-        log.info("Application starting")
-
-    def get_value(self) -> str:
-        return f"Service2 returned: {self.service2.get_value()}"
-
-
-container = Container()
-container.add_singleton(get_logger)
-container.add_transient(Service1)
-container.add_transient(Service2)
-container.add_transient(Application)
-
-provider = container.provider() # container is sealed beyond this point
-
-app = provider.provide(Application)
-
-value = app.get_value() # => "Service2 returned: Service1 returned: Some value"
-```
-
-## Full documentation
-
-[Go to documentation](https://github.com/apmadsen/dependency-injection-pattern/blob/main/docs/documentation.md)