dependency-injection-pattern 0.0.6__tar.gz → 0.0.8__tar.gz

{dependency_injection_pattern-0.0.6/src/dependency_injection_pattern.egg-info → dependency_injection_pattern-0.0.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dependency-injection-pattern
-Version: 0.0.6
+Version: 0.0.8
 Summary: Python implementation of the Dependency Injection pattern.
 Author-email: Anders Madsen <anders.madsen@alphavue.com>
 License-Expression: MIT
@@ -14,22 +14,23 @@ Classifier: Intended Audience :: Developers
 Classifier: Natural Language :: English
 Classifier: Programming Language :: Python :: 3 :: Only
 Classifier: Programming Language :: Python :: 3
-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 :: 3.15
 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.16,>=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: typing-utilities<0.2,>=0.1.0
 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"
+Requires-Dist: pytest>=9.0; extra == "test"
+Requires-Dist: pytest-cov>=7.0; extra == "test"
 Dynamic: license-file
 
 [![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)
@@ -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.8/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.6 → dependency_injection_pattern-0.0.8}/pyproject.toml

@@ -18,10 +18,11 @@ classifiers = [
     "Natural Language :: English",
     "Programming Language :: Python :: 3 :: Only",
     "Programming Language :: Python :: 3",
-    "Programming Language :: Python :: 3.10",
     "Programming Language :: Python :: 3.11",
     "Programming Language :: Python :: 3.12",
     "Programming Language :: Python :: 3.13",
+    "Programming Language :: Python :: 3.14",
+    "Programming Language :: Python :: 3.15",
     "Programming Language :: Python",
     "Topic :: Software Development :: Libraries :: Python Modules",
     "Topic :: Software Development :: Libraries",
@@ -31,15 +32,15 @@ dependencies = [
     "typing-utilities >= 0.1.0, < 0.2",
     "runtime-reflection-lite >= 0.2.0, < 0.3"
 ]
-requires-python = ">=3.10"
+requires-python = ">= 3.11, < 3.16"
 
 [project.urls]
 repository = "https://github.com/apmadsen/dependency-injection-pattern"
 
 [project.optional-dependencies]
 test = [
-    "pytest>=8.3",
-    "pytest-cov>=6.1",
+    "pytest>=9.0",
+    "pytest-cov>=7.0",
 ]
 
 [tool.setuptools-git-versioning]

{dependency_injection_pattern-0.0.6 → dependency_injection_pattern-0.0.8/src/dependency_injection_pattern.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dependency-injection-pattern
-Version: 0.0.6
+Version: 0.0.8
 Summary: Python implementation of the Dependency Injection pattern.
 Author-email: Anders Madsen <anders.madsen@alphavue.com>
 License-Expression: MIT
@@ -14,22 +14,23 @@ Classifier: Intended Audience :: Developers
 Classifier: Natural Language :: English
 Classifier: Programming Language :: Python :: 3 :: Only
 Classifier: Programming Language :: Python :: 3
-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 :: 3.15
 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.16,>=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: typing-utilities<0.2,>=0.1.0
 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"
+Requires-Dist: pytest>=9.0; extra == "test"
+Requires-Dist: pytest-cov>=7.0; extra == "test"
 Dynamic: license-file
 
 [![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)
@@ -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.6 → dependency_injection_pattern-0.0.8}/src/dependency_injection_pattern.egg-info/SOURCES.txt

@@ -21,6 +21,7 @@ src/di/core/exceptions/add_exception.py
 src/di/core/exceptions/container_sealed_error.py
 src/di/core/exceptions/factory_provide_exception.py
 src/di/core/exceptions/implementation_exception.py
+src/di/core/exceptions/internal_exception.py
 src/di/core/exceptions/provide_exception.py
 src/di/core/exceptions/seal_exception.py
 src/di/core/factories/dependency.py

{dependency_injection_pattern-0.0.6 → dependency_injection_pattern-0.0.8}/src/dependency_injection_pattern.egg-info/requires.txt

@@ -2,5 +2,5 @@ typing-utilities<0.2,>=0.1.0
 runtime-reflection-lite<0.3,>=0.2.0
 
 [test]
-pytest>=8.3
-pytest-cov>=6.1
+pytest>=9.0
+pytest-cov>=7.0

{dependency_injection_pattern-0.0.6 → dependency_injection_pattern-0.0.8}/src/di/__init__.py

@@ -1,13 +1,13 @@
 from di.core.container import Container
-from di.core.provider import Provider
-from di.core.scope import Scope
 from di.core.default_scope import DefaultScope
 from di.core.factory import Factory
+from di.core.provider import Provider
+from di.core.scope import Scope
 
 __all__ = [
     'Container',
-    'Provider',
-    'Scope',
     'DefaultScope',
-    'Factory'
+    'Factory',
+    'Provider',
+    'Scope'
 ]