pyboot-framework 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- pyboot_framework-0.1.0/PKG-INFO +571 -0
- pyboot_framework-0.1.0/README.md +551 -0
- pyboot_framework-0.1.0/pyproject.toml +53 -0
- pyboot_framework-0.1.0/setup.cfg +4 -0
- pyboot_framework-0.1.0/src/pyboot/__init__.py +6 -0
- pyboot_framework-0.1.0/src/pyboot/core/__init__.py +0 -0
- pyboot_framework-0.1.0/src/pyboot/core/application.py +162 -0
- pyboot_framework-0.1.0/src/pyboot/core/builtins/BuiltInAttr.py +8 -0
- pyboot_framework-0.1.0/src/pyboot/core/builtins/__init__.py +0 -0
- pyboot_framework-0.1.0/src/pyboot/core/builtins/component.py +58 -0
- pyboot_framework-0.1.0/src/pyboot/core/builtins/configuration.py +97 -0
- pyboot_framework-0.1.0/src/pyboot/core/builtins/py.typed +0 -0
- pyboot_framework-0.1.0/src/pyboot/core/exceptions.py +72 -0
- pyboot_framework-0.1.0/src/pyboot/core/ioc.py +119 -0
- pyboot_framework-0.1.0/src/pyboot/core/plugin_loader.py +30 -0
- pyboot_framework-0.1.0/src/pyboot/core/pyboot_context.py +16 -0
- pyboot_framework-0.1.0/src/pyboot/core/pyboot_plugin.py +52 -0
- pyboot_framework-0.1.0/src/pyboot/core/types.py +7 -0
- pyboot_framework-0.1.0/src/pyboot/py.typed +0 -0
- pyboot_framework-0.1.0/src/pyboot_framework.egg-info/PKG-INFO +571 -0
- pyboot_framework-0.1.0/src/pyboot_framework.egg-info/SOURCES.txt +22 -0
- pyboot_framework-0.1.0/src/pyboot_framework.egg-info/dependency_links.txt +1 -0
- pyboot_framework-0.1.0/src/pyboot_framework.egg-info/entry_points.txt +3 -0
- pyboot_framework-0.1.0/src/pyboot_framework.egg-info/top_level.txt +1 -0
|
@@ -0,0 +1,571 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: pyboot-framework
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: A lightweight, extensible Python framework for building applications with dependency injection and a modular plugin architecture.
|
|
5
|
+
Author: Siddharth Karn
|
|
6
|
+
License-Expression: MIT
|
|
7
|
+
Keywords: pyboot,python-framework,dependency-injection,inversion-of-control,ioc,plugin-architecture,starlette
|
|
8
|
+
Classifier: Development Status :: 3 - Alpha
|
|
9
|
+
Classifier: Framework :: AsyncIO
|
|
10
|
+
Classifier: Intended Audience :: Developers
|
|
11
|
+
Classifier: Operating System :: OS Independent
|
|
12
|
+
Classifier: Programming Language :: Python :: 3
|
|
13
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
14
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
15
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
16
|
+
Classifier: Topic :: Internet :: WWW/HTTP :: HTTP Servers
|
|
17
|
+
Classifier: Topic :: Software Development :: Libraries :: Python Modules
|
|
18
|
+
Requires-Python: >=3.11
|
|
19
|
+
Description-Content-Type: text/markdown
|
|
20
|
+
|
|
21
|
+
# PyBoot
|
|
22
|
+
|
|
23
|
+
**A lightweight, extensible Python framework for building applications with Inversion of Control, Dependency Injection, and a modular plugin architecture.**
|
|
24
|
+
|
|
25
|
+
[](https://www.python.org/)
|
|
26
|
+
[](https://pypi.org/project/pyboot-framework/)
|
|
27
|
+
[](LICENSE)
|
|
28
|
+
|
|
29
|
+
PyBoot is a Python framework designed around a simple idea: application components should focus on their responsibilities, while the framework handles object creation, dependency resolution, lifecycle management, and application infrastructure.
|
|
30
|
+
|
|
31
|
+
Inspired by the programming model of frameworks like Spring Boot, PyBoot brings a structured IoC container and dependency injection system to Python without forcing every application to depend on a large collection of built-in features.
|
|
32
|
+
|
|
33
|
+
Its architecture is designed to remain lightweight at its core while allowing developers to extend its capabilities through plugins.
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Table of Contents
|
|
38
|
+
|
|
39
|
+
- [Why PyBoot?](#why-pyboot)
|
|
40
|
+
- [Core Philosophy](#core-philosophy)
|
|
41
|
+
- [Features](#features)
|
|
42
|
+
- [Installation](#installation)
|
|
43
|
+
- [Getting Started](#getting-started)
|
|
44
|
+
- [Inversion of Control](#inversion-of-control)
|
|
45
|
+
- [Dependency Injection](#dependency-injection)
|
|
46
|
+
- [Component Management](#component-management)
|
|
47
|
+
- [Application Lifecycle](#application-lifecycle)
|
|
48
|
+
- [Plugin Architecture](#plugin-architecture)
|
|
49
|
+
- [Web Integration](#web-integration)
|
|
50
|
+
- [Project Structure](#project-structure)
|
|
51
|
+
- [Design Philosophy](#design-philosophy)
|
|
52
|
+
- [Roadmap](#roadmap)
|
|
53
|
+
- [Contributing](#contributing)
|
|
54
|
+
- [License](#license)
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Why PyBoot?
|
|
59
|
+
|
|
60
|
+
Python has several excellent frameworks for building applications. However, when applications grow, managing dependencies, object creation, shared resources, and application initialization can become increasingly difficult.
|
|
61
|
+
|
|
62
|
+
Developers often end up manually constructing objects and passing dependencies throughout the application.
|
|
63
|
+
|
|
64
|
+
Consider a simple dependency chain:
|
|
65
|
+
|
|
66
|
+
```text
|
|
67
|
+
UserController
|
|
68
|
+
|
|
|
69
|
+
v
|
|
70
|
+
UserService
|
|
71
|
+
|
|
|
72
|
+
v
|
|
73
|
+
UserRepository
|
|
74
|
+
|
|
|
75
|
+
v
|
|
76
|
+
DatabaseClient
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Without a dependency management system, the developer is responsible for constructing every object and ensuring that the correct dependencies are passed to each constructor.
|
|
80
|
+
|
|
81
|
+
As the application grows, this responsibility becomes increasingly repetitive.
|
|
82
|
+
|
|
83
|
+
PyBoot aims to solve this problem through Inversion of Control.
|
|
84
|
+
|
|
85
|
+
Instead of manually managing application objects, developers declare their components and dependencies. PyBoot takes responsibility for discovering components, constructing objects, resolving dependencies, and managing their lifecycle.
|
|
86
|
+
|
|
87
|
+
The goal is not to introduce another collection of abstractions. It is to provide a predictable application architecture with minimal framework overhead.
|
|
88
|
+
|
|
89
|
+
## Core Philosophy
|
|
90
|
+
|
|
91
|
+
PyBoot is built around four principles.
|
|
92
|
+
|
|
93
|
+
### 1. Inversion of Control
|
|
94
|
+
|
|
95
|
+
Application objects should not be responsible for constructing their own dependencies.
|
|
96
|
+
|
|
97
|
+
The framework manages object creation and dependency resolution through a centralized IoC container.
|
|
98
|
+
|
|
99
|
+
### 2. Constructor-based Dependency Injection
|
|
100
|
+
|
|
101
|
+
Dependencies should be explicitly declared through constructors.
|
|
102
|
+
|
|
103
|
+
This makes dependencies visible, improves testability, and avoids unnecessary service locators or hidden global state.
|
|
104
|
+
|
|
105
|
+
### 3. Lightweight Core
|
|
106
|
+
|
|
107
|
+
The core should contain only the fundamental infrastructure required to manage an application.
|
|
108
|
+
|
|
109
|
+
Features such as web routing, database integration, ORM mapping, validation, and scheduling should be provided through optional extensions.
|
|
110
|
+
|
|
111
|
+
This prevents developers from installing unnecessary dependencies when they only need the IoC container.
|
|
112
|
+
|
|
113
|
+
### 4. Extensibility Through Plugins
|
|
114
|
+
|
|
115
|
+
PyBoot is designed to allow developers to extend the framework without modifying its internal implementation.
|
|
116
|
+
|
|
117
|
+
Plugins can participate in application registration, initialization, and lifecycle management.
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Features
|
|
122
|
+
|
|
123
|
+
PyBoot focuses on providing a foundation for structured Python applications.
|
|
124
|
+
|
|
125
|
+
| Feature | Description |
|
|
126
|
+
|---|---|
|
|
127
|
+
| IoC Container | Centralized management of application objects |
|
|
128
|
+
| Dependency Injection | Automatic constructor dependency resolution |
|
|
129
|
+
| Component Discovery | Discover application components |
|
|
130
|
+
| Lifecycle Management | Control object initialization and application startup |
|
|
131
|
+
| Plugin Architecture | Extend framework capabilities independently |
|
|
132
|
+
| Modular Design | Keep optional functionality outside the core |
|
|
133
|
+
| Python Type Hints | Use Python type annotations for dependency resolution |
|
|
134
|
+
| Starlette Integration | Support web application development through web integration |
|
|
135
|
+
|
|
136
|
+
Some capabilities may depend on the availability of their respective extensions.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Installation
|
|
141
|
+
|
|
142
|
+
Install PyBoot using pip:
|
|
143
|
+
|
|
144
|
+
```bash
|
|
145
|
+
pip install pyboot-framework
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
PyBoot requires Python 3.11 or newer.
|
|
149
|
+
|
|
150
|
+
The core package is designed to remain lightweight. Optional integrations should be installed separately when required.
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Getting Started
|
|
155
|
+
|
|
156
|
+
The following example illustrates the intended component-oriented programming model.
|
|
157
|
+
|
|
158
|
+
### 1. Define a component
|
|
159
|
+
|
|
160
|
+
A component is an object managed by the PyBoot IoC container.
|
|
161
|
+
|
|
162
|
+
```python
|
|
163
|
+
from pyboot import Component
|
|
164
|
+
|
|
165
|
+
|
|
166
|
+
@Component
|
|
167
|
+
class UserService:
|
|
168
|
+
|
|
169
|
+
def get_user(self, user_id: int):
|
|
170
|
+
return {
|
|
171
|
+
"id": user_id,
|
|
172
|
+
"name": "Siddharth"
|
|
173
|
+
}
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
By marking a class as a component, it becomes eligible for framework-managed object creation and dependency injection.
|
|
177
|
+
|
|
178
|
+
### 2. Declare dependencies
|
|
179
|
+
|
|
180
|
+
Components can declare their dependencies through constructor parameters.
|
|
181
|
+
|
|
182
|
+
```python
|
|
183
|
+
from pyboot import Component
|
|
184
|
+
|
|
185
|
+
|
|
186
|
+
@Component
|
|
187
|
+
class UserRepository:
|
|
188
|
+
|
|
189
|
+
def find_by_id(self, user_id: int):
|
|
190
|
+
return {
|
|
191
|
+
"id": user_id,
|
|
192
|
+
"name": "Siddharth"
|
|
193
|
+
}
|
|
194
|
+
|
|
195
|
+
|
|
196
|
+
@Component
|
|
197
|
+
class UserService:
|
|
198
|
+
|
|
199
|
+
def __init__(self, repository: UserRepository):
|
|
200
|
+
self.repository = repository
|
|
201
|
+
|
|
202
|
+
def get_user(self, user_id: int):
|
|
203
|
+
return self.repository.find_by_id(user_id)
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
Here, `UserService` does not create `UserRepository` itself.
|
|
207
|
+
|
|
208
|
+
Instead, PyBoot resolves the dependency and supplies the appropriate component instance.
|
|
209
|
+
|
|
210
|
+
This keeps object construction separate from application business logic.
|
|
211
|
+
|
|
212
|
+
### 3. Build application components
|
|
213
|
+
|
|
214
|
+
The framework discovers registered components and manages their dependencies through its IoC container.
|
|
215
|
+
|
|
216
|
+
The exact bootstrap API depends on the application integration being used.
|
|
217
|
+
|
|
218
|
+
---
|
|
219
|
+
|
|
220
|
+
## Inversion of Control
|
|
221
|
+
|
|
222
|
+
Inversion of Control is the foundation of PyBoot.
|
|
223
|
+
|
|
224
|
+
Traditionally, application code controls object creation:
|
|
225
|
+
|
|
226
|
+
```python
|
|
227
|
+
class UserRepository:
|
|
228
|
+
pass
|
|
229
|
+
|
|
230
|
+
|
|
231
|
+
class UserService:
|
|
232
|
+
|
|
233
|
+
def __init__(self):
|
|
234
|
+
self.repository = UserRepository()
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
This creates a direct dependency between `UserService` and the construction of `UserRepository`.
|
|
238
|
+
|
|
239
|
+
With PyBoot, object creation is delegated to the framework:
|
|
240
|
+
|
|
241
|
+
```python
|
|
242
|
+
@Component
|
|
243
|
+
class UserRepository:
|
|
244
|
+
pass
|
|
245
|
+
|
|
246
|
+
|
|
247
|
+
@Component
|
|
248
|
+
class UserService:
|
|
249
|
+
|
|
250
|
+
def __init__(self, repository: UserRepository):
|
|
251
|
+
self.repository = repository
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
The framework takes responsibility for:
|
|
255
|
+
|
|
256
|
+
1. Discovering registered component classes.
|
|
257
|
+
2. Identifying their constructor dependencies.
|
|
258
|
+
3. Resolving dependencies from the IoC container.
|
|
259
|
+
4. Creating component instances.
|
|
260
|
+
5. Managing the resulting instances.
|
|
261
|
+
|
|
262
|
+
This provides a centralized mechanism for managing application objects.
|
|
263
|
+
|
|
264
|
+
### Dependency Resolution
|
|
265
|
+
|
|
266
|
+
PyBoot uses Python type annotations to identify constructor dependencies.
|
|
267
|
+
|
|
268
|
+
For example:
|
|
269
|
+
|
|
270
|
+
```python
|
|
271
|
+
@Component
|
|
272
|
+
class DatabaseClient:
|
|
273
|
+
pass
|
|
274
|
+
|
|
275
|
+
|
|
276
|
+
@Component
|
|
277
|
+
class UserRepository:
|
|
278
|
+
|
|
279
|
+
def __init__(self, database: DatabaseClient):
|
|
280
|
+
self.database = database
|
|
281
|
+
|
|
282
|
+
|
|
283
|
+
@Component
|
|
284
|
+
class UserService:
|
|
285
|
+
|
|
286
|
+
def __init__(self, repository: UserRepository):
|
|
287
|
+
self.repository = repository
|
|
288
|
+
```
|
|
289
|
+
|
|
290
|
+
The dependency graph is:
|
|
291
|
+
|
|
292
|
+
```text
|
|
293
|
+
UserService
|
|
294
|
+
|
|
|
295
|
+
v
|
|
296
|
+
UserRepository
|
|
297
|
+
|
|
|
298
|
+
v
|
|
299
|
+
DatabaseClient
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
The IoC container resolves the dependency chain when constructing the application components.
|
|
303
|
+
|
|
304
|
+
---
|
|
305
|
+
|
|
306
|
+
## Component Management
|
|
307
|
+
|
|
308
|
+
Components are the fundamental building blocks of a PyBoot application.
|
|
309
|
+
|
|
310
|
+
A component is a class whose instance is managed by the framework.
|
|
311
|
+
|
|
312
|
+
```python
|
|
313
|
+
@Component
|
|
314
|
+
class EmailService:
|
|
315
|
+
|
|
316
|
+
def send(self, recipient: str, message: str):
|
|
317
|
+
print(f"Sending email to {recipient}")
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
Components allow application developers to organize functionality into independent units.
|
|
321
|
+
|
|
322
|
+
A component can depend on other components, allowing PyBoot to construct complex dependency graphs automatically.
|
|
323
|
+
|
|
324
|
+
### Component Responsibilities
|
|
325
|
+
|
|
326
|
+
Components should:
|
|
327
|
+
|
|
328
|
+
- Encapsulate a specific responsibility.
|
|
329
|
+
- Declare dependencies explicitly.
|
|
330
|
+
- Avoid manually constructing framework-managed dependencies.
|
|
331
|
+
- Keep business logic independent of application bootstrap logic.
|
|
332
|
+
|
|
333
|
+
---
|
|
334
|
+
|
|
335
|
+
## Application Lifecycle
|
|
336
|
+
|
|
337
|
+
Application initialization is an important responsibility of a framework.
|
|
338
|
+
|
|
339
|
+
PyBoot is designed around a controlled initialization process rather than requiring every extension to independently initialize itself.
|
|
340
|
+
|
|
341
|
+
The conceptual lifecycle consists of:
|
|
342
|
+
|
|
343
|
+
```text
|
|
344
|
+
Application Bootstrap
|
|
345
|
+
|
|
|
346
|
+
v
|
|
347
|
+
Plugin Registration
|
|
348
|
+
|
|
|
349
|
+
v
|
|
350
|
+
Component Discovery
|
|
351
|
+
|
|
|
352
|
+
v
|
|
353
|
+
Dependency Resolution
|
|
354
|
+
|
|
|
355
|
+
v
|
|
356
|
+
Bean Creation
|
|
357
|
+
|
|
|
358
|
+
v
|
|
359
|
+
Plugin Initialization
|
|
360
|
+
|
|
|
361
|
+
v
|
|
362
|
+
Application Ready
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
This separation allows plugins to register their capabilities before application initialization and perform setup after the required application objects are available.
|
|
366
|
+
|
|
367
|
+
---
|
|
368
|
+
|
|
369
|
+
## Plugin Architecture
|
|
370
|
+
|
|
371
|
+
One of PyBoot's primary design goals is extensibility.
|
|
372
|
+
|
|
373
|
+
Rather than putting every framework feature into the core package, PyBoot provides a plugin architecture through which optional capabilities can be introduced.
|
|
374
|
+
|
|
375
|
+
For example:
|
|
376
|
+
|
|
377
|
+
| Plugin | Responsibility |
|
|
378
|
+
|---|---|
|
|
379
|
+
| Web | HTTP routing, controllers, middleware |
|
|
380
|
+
| ORM | Object-relational mapping and entity management |
|
|
381
|
+
| Database | Database connectivity and repositories |
|
|
382
|
+
| Validation | Request and data validation |
|
|
383
|
+
| Scheduling | Scheduled task execution |
|
|
384
|
+
| Configuration | External configuration management |
|
|
385
|
+
|
|
386
|
+
These are examples of potential extensions, not a claim that every plugin is currently available.
|
|
387
|
+
|
|
388
|
+
### Why Plugins?
|
|
389
|
+
|
|
390
|
+
Consider an application that only needs dependency injection.
|
|
391
|
+
|
|
392
|
+
It should not need to install an ORM, web server, validation engine, or scheduling system.
|
|
393
|
+
|
|
394
|
+
Similarly, an application that needs HTTP routing should be able to install the web integration without forcing database dependencies into its environment.
|
|
395
|
+
|
|
396
|
+
This keeps the core independent of optional infrastructure.
|
|
397
|
+
|
|
398
|
+
### Developing Plugins
|
|
399
|
+
|
|
400
|
+
PyBoot is intended to provide extension points for plugin developers.
|
|
401
|
+
|
|
402
|
+
A plugin should be able to participate in framework registration and application initialization without requiring modifications to the core.
|
|
403
|
+
|
|
404
|
+
The plugin lifecycle is designed around two important phases:
|
|
405
|
+
|
|
406
|
+
**Registration phase**
|
|
407
|
+
|
|
408
|
+
Used to register metadata, components, integrations, and other framework capabilities.
|
|
409
|
+
|
|
410
|
+
**Loading phase**
|
|
411
|
+
|
|
412
|
+
Used to perform initialization that requires framework-managed objects to exist.
|
|
413
|
+
|
|
414
|
+
This separation helps avoid initialization-order problems and allows plugins to integrate with the application lifecycle.
|
|
415
|
+
|
|
416
|
+
Plugin API documentation will be expanded as the extension interfaces stabilize.
|
|
417
|
+
|
|
418
|
+
---
|
|
419
|
+
|
|
420
|
+
## Web Integration
|
|
421
|
+
|
|
422
|
+
PyBoot is designed to support web application development through Starlette-based integration.
|
|
423
|
+
|
|
424
|
+
The intention is to combine Starlette's lightweight ASGI infrastructure with PyBoot's IoC container and component management.
|
|
425
|
+
|
|
426
|
+
A typical web application can be organized into:
|
|
427
|
+
|
|
428
|
+
```text
|
|
429
|
+
Application
|
|
430
|
+
|
|
|
431
|
+
+-- Controllers
|
|
432
|
+
|
|
|
433
|
+
+-- Services
|
|
434
|
+
|
|
|
435
|
+
+-- Repositories
|
|
436
|
+
|
|
|
437
|
+
+-- Infrastructure
|
|
438
|
+
```
|
|
439
|
+
|
|
440
|
+
The web integration is responsible for HTTP-specific functionality, while the core remains focused on application object management.
|
|
441
|
+
|
|
442
|
+
This separation means that web-specific dependencies do not need to become mandatory dependencies of the core package.
|
|
443
|
+
|
|
444
|
+
---
|
|
445
|
+
|
|
446
|
+
## Project Structure
|
|
447
|
+
|
|
448
|
+
A typical application using PyBoot could follow this structure:
|
|
449
|
+
|
|
450
|
+
```text
|
|
451
|
+
my-application/
|
|
452
|
+
│
|
|
453
|
+
├── app/
|
|
454
|
+
│ │
|
|
455
|
+
│ ├── controllers/
|
|
456
|
+
│ │ └── user_controller.py
|
|
457
|
+
│ │
|
|
458
|
+
│ ├── services/
|
|
459
|
+
│ │ └── user_service.py
|
|
460
|
+
│ │
|
|
461
|
+
│ ├── repositories/
|
|
462
|
+
│ │ └── user_repository.py
|
|
463
|
+
│ │
|
|
464
|
+
│ ├── infrastructure/
|
|
465
|
+
│ │ └── database.py
|
|
466
|
+
│ │
|
|
467
|
+
│ └── main.py
|
|
468
|
+
│
|
|
469
|
+
├── tests/
|
|
470
|
+
│
|
|
471
|
+
├── requirements.txt
|
|
472
|
+
└── README.md
|
|
473
|
+
```
|
|
474
|
+
|
|
475
|
+
This structure is only a recommendation. PyBoot aims to avoid enforcing a particular application directory structure.
|
|
476
|
+
|
|
477
|
+
Developers should be able to organize their applications according to their requirements.
|
|
478
|
+
|
|
479
|
+
---
|
|
480
|
+
|
|
481
|
+
## Design Philosophy
|
|
482
|
+
|
|
483
|
+
PyBoot is not intended to replace every Python framework.
|
|
484
|
+
|
|
485
|
+
Its purpose is to provide a structured foundation for building applications with centralized object management and extensible infrastructure.
|
|
486
|
+
|
|
487
|
+
A few important design decisions guide its development:
|
|
488
|
+
|
|
489
|
+
**Explicit dependencies over hidden dependencies**
|
|
490
|
+
|
|
491
|
+
Constructor injection makes the dependency graph visible and easier to understand.
|
|
492
|
+
|
|
493
|
+
**Composition over inheritance**
|
|
494
|
+
|
|
495
|
+
Application functionality should be assembled through components and plugins rather than requiring developers to inherit from large framework classes.
|
|
496
|
+
|
|
497
|
+
**Optional integrations over mandatory dependencies**
|
|
498
|
+
|
|
499
|
+
The core should not require developers to install functionality they do not use.
|
|
500
|
+
|
|
501
|
+
**Centralized lifecycle management**
|
|
502
|
+
|
|
503
|
+
Application initialization should follow a predictable lifecycle instead of depending on arbitrary plugin initialization order.
|
|
504
|
+
|
|
505
|
+
**Extensibility without unnecessary complexity**
|
|
506
|
+
|
|
507
|
+
Plugins should extend the framework through well-defined interfaces rather than modifying its internal implementation.
|
|
508
|
+
|
|
509
|
+
---
|
|
510
|
+
|
|
511
|
+
## Roadmap
|
|
512
|
+
|
|
513
|
+
PyBoot is currently under active development.
|
|
514
|
+
|
|
515
|
+
The following areas represent its development direction:
|
|
516
|
+
|
|
517
|
+
- [x] Initial IoC container architecture
|
|
518
|
+
- [x] Constructor-based dependency injection
|
|
519
|
+
- [x] Component metadata and discovery
|
|
520
|
+
- [ ] Stable application lifecycle API
|
|
521
|
+
- [ ] Stable plugin development API
|
|
522
|
+
- [ ] Configuration management
|
|
523
|
+
- [ ] Bean scopes and lifecycle controls
|
|
524
|
+
- [ ] Web integration
|
|
525
|
+
- [ ] Controller and routing support
|
|
526
|
+
- [ ] Middleware integration
|
|
527
|
+
- [ ] Global exception handling
|
|
528
|
+
- [ ] ORM integration
|
|
529
|
+
- [ ] Repository abstraction
|
|
530
|
+
- [ ] Validation integration
|
|
531
|
+
- [ ] Comprehensive documentation
|
|
532
|
+
- [ ] Testing and performance benchmarks
|
|
533
|
+
|
|
534
|
+
Roadmap items should be updated as features are implemented and released.
|
|
535
|
+
|
|
536
|
+
---
|
|
537
|
+
|
|
538
|
+
## Contributing
|
|
539
|
+
|
|
540
|
+
Contributions, suggestions, bug reports, and discussions are welcome.
|
|
541
|
+
|
|
542
|
+
If you want to contribute:
|
|
543
|
+
|
|
544
|
+
1. Fork the repository.
|
|
545
|
+
2. Clone your fork.
|
|
546
|
+
3. Create a feature branch.
|
|
547
|
+
4. Implement your changes.
|
|
548
|
+
5. Add or update tests.
|
|
549
|
+
6. Submit a pull request.
|
|
550
|
+
|
|
551
|
+
For substantial architectural changes, open an issue first to discuss the proposed design.
|
|
552
|
+
|
|
553
|
+
Please keep contributions consistent with PyBoot's core philosophy: lightweight infrastructure, clear abstractions, and extensibility without unnecessary complexity.
|
|
554
|
+
|
|
555
|
+
---
|
|
556
|
+
|
|
557
|
+
## License
|
|
558
|
+
|
|
559
|
+
PyBoot is licensed under the MIT License.
|
|
560
|
+
|
|
561
|
+
See the [LICENSE](LICENSE) file for details.
|
|
562
|
+
|
|
563
|
+
---
|
|
564
|
+
|
|
565
|
+
## Author
|
|
566
|
+
|
|
567
|
+
Developed by **Siddharth Karn**.
|
|
568
|
+
|
|
569
|
+
If you are interested in contributing, improving the architecture, or building extensions for PyBoot, contributions are welcome.
|
|
570
|
+
|
|
571
|
+
**PyBoot — A lightweight foundation for structured Python applications.**
|