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.
@@ -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
+ [![Python](https://img.shields.io/badge/Python-3.11%2B-blue)](https://www.python.org/)
26
+ [![PyPI](https://img.shields.io/pypi/v/pyboot-framework)](https://pypi.org/project/pyboot-framework/)
27
+ [![License](https://img.shields.io/badge/License-MIT-green.svg)](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.**