cullinan 0.93

Cullinan — A pluggable IoC/DI web framework

   _____      _ _ _
  / ____|    | | (_)
 | |    _   _| | |_ _ __   __ _ _ __
 | |   | | | | | | | '_ \ / _` | '_ \
 | |___| |_| | | | | | | | (_| | | | |
  \_____\__,_|_|_|_|_| |_|\__,_|_| |_|

Cullinan

A business-first Python web framework for building applications through decorators, module boundaries, and built-in IoC/DI.

Cullinan is a Python Web Framework for developers who want to organize applications around business services, controllers, and methods instead of manually wiring an app object. Its default path is decorator-first discovery plus @application + @configure(...), with @module used as the application boundary when ownership, runtime structure, and stability matter. The framework-facing API stays engine-neutral: Cullinan internally bridges your business application into Tornado or ASGI runtimes instead of making a concrete server framework the primary developer mental model.

---

What is Cullinan?

Cullinan is designed to make the framework work around your business architecture, not the other way around.

• Business-first application model - write services, controllers, middleware, and methods first
• Decorator-first discovery - let Python imports and decorator metadata assemble the runtime
• Structured module boundaries - use @module to express ownership and runtime boundaries
• Built-in IoC/DI and lifecycle - keep application wiring inside the framework model
• Engine-neutral Web facade - build against Cullinan semantics while the framework adapts to Tornado or ASGI internally
• Public semantic path - build, run, test, and extend applications through stable public APIs

Cullinan is not centered on treating an app object as a manual registration hub. The recommended development flow is to declare business components, define a root module when structure matters, and let the framework assemble the application runtime.

---

Why Cullinan?

1. Framework semantics before manual wiring

Cullinan gives you a clear application model: declare components with decorators, let the framework discover them, and keep explicit runtime internals as an advanced path rather than the default onboarding path.

2. Application boundaries that scale past toy examples

@module is more than a naming convention. It is the structured boundary for owned packages, runtime composition, and higher-level lifecycle behavior when your application grows.

3. Web, DI, lifecycle, and testing in one model

Routing, parameter binding, dependency injection, lifecycle hooks, middleware, and test flow all sit inside one framework vocabulary instead of forcing developers to stitch together multiple unrelated patterns.

4. A Pythonic path for business applications

Cullinan is designed to keep developers focused on business architecture and business methods. You can stay on the public path for most application work and only move into internals when you intentionally need advanced extension behavior.

5. A clearer semantic package surface

Cullinan now exposes a clearer framework-shaped package surface:

• cullinan - recommended public startup and declaration API for application code
• cullinan.web - controllers, route decorators, request/response, parameters, middleware
• cullinan.core - IoC/DI, lifecycle, context, and semantic rules
• cullinan.application - advanced application semantics for maintainers and framework-aware integrations
• cullinan.testing - test-facing helpers
• cullinan.runtime / cullinan.transport - advanced discovery and adapter boundaries
• cullinan.support - constrained support utilities, not a second public app path

---

Framework capabilities

Capability layer	What Cullinan provides
Application composition	@application + @configure(...), decorator-driven discovery, structured runtime assembly
Web API model	cullinan.web facade for @controller, RESTful decorators, WebResponse, parameters, middleware
Parameter system	Typed Path, Query, Body, validation, conversion, and controller-method binding
IoC/DI and lifecycle	Inject(), InjectByName(), request scope, startup/shutdown hooks, component lifecycle
Runtime boundaries	@module ownership, clearer package structure, better runtime organization
Testing and delivery	get_asgi_app(), resettable registries, packaging-friendly runtime, cross-platform support

Cullinan's goal is not to expose every internal knob on the README homepage. The goal is to provide a coherent framework model that remains readable from first contact through production use.

---

Install

Cullinan is published on PyPI and currently supports Python 3.7+.

pip install -U pip
pip install cullinan

After installation, start from the minimal example in examples/minimal_app/ or the repository guide in docs/examples.md.

---

Quick Start

The recommended starting point is: define business components, decorate them, and declare the application entry with @configure(...) + @application + main().

from cullinan import application, configure
from cullinan.core import service
from cullinan.web import controller, get_api


@service
class GreetingService:
    def greet(self) -> str:
        return "Hello from Cullinan!"


@controller(url="/hello")
class HelloController:
    greeting_service: GreetingService  # ← 构造注入：一行就够了

    @get_api(url="")
    def hello(self):
        return {"message": self.greeting_service.greet()}


@configure(user_packages=["minimal_app"], server_port=4080)
@application
def main(): ...

Run it:

python -m minimal_app

Then open:

http://localhost:4080/hello

This example shows the default Cullinan path:

• business service first
• controller methods as the public web surface
• @application + @configure(...) + main() as the startup flow
• @module available when explicit runtime boundaries are needed
• runtime backend selection delegated to Cullinan instead of driving application structure

---

Learning path

If you are new to Cullinan, use this order:

1. examples/minimal_app/ - shortest public entrypoint
2. examples/controller_service_inject/ - service/controller layering with Inject()
3. examples/middleware_and_module/ - @module boundaries and middleware semantics
4. examples/parameter_handling/ - method-level Path, Query, and Body
5. examples/testing_flow/ - public-API testing with get_asgi_app()

Then move into the documentation knowledge base:

• docs/README.md - English knowledge base home
• docs/zh/README.md - 中文知识库首页
• docs/getting_started.md - recommended application entry
• docs/framework_semantics.md - framework concepts and semantics
• docs/examples.md - example navigation page

---

Documentation

English

• Documentation home
• Getting Started
• Framework Semantics
• Examples
• Dependency Injection Guide
• Web Runtime Guide
• Static Files and SPA Guide
• Parameter System Guide
• Testing & Verification

中文

• 文档首页
• 快速开始
• 框架语义
• 示例导航
• 依赖注入指南
• Web Runtime 指南
• 静态文件与 SPA 指南
• 参数系统指南
• 测试与验证

---

Current series

v0.93a8 makes the public application path more explicit around:

• @application + @configure(...) + main() as the startup flow
• decorator-first discovery through Python imports
• @module as the structured boundary for runtime ownership
• built-in IoC/DI, lifecycle, and semantic diagnostics
• a semantic package surface centered on the top-level cullinan API, with advanced semantic namespaces under cullinan.application, cullinan.web, and cullinan.core
• engine-neutral runtime selection over Tornado / ASGI backends

Version-specific details and migration notes live in the documentation knowledge base rather than in the homepage narrative.

---

Project links

• GitHub: https://github.com/plumeink/Cullinan
• PyPI: https://pypi.org/project/cullinan/
• Issues: https://github.com/plumeink/Cullinan/issues
• Discussions: https://github.com/plumeink/Cullinan/discussions

---

License

MIT License - see LICENSE for details.