Lab 12: Plugin Architecture

Objective

Build production-grade extension systems in Python: importlib-based plugin loading, __init_subclass__ registry, entry-point-style discovery, hook systems, middleware chains, and a dynamic configuration DSL.

Background

Every major Python framework uses plugins: Django apps, Flask blueprints, pytest plugins, FastAPI routers. The patterns are consistent: register by subclassing, discover by naming convention, configure by entry points. Understanding these patterns lets you build extensible systems that third parties can extend without modifying your core code.

Time

30 minutes

Prerequisites

  • Lab 01 (Metaprogramming), Practitioner Lab 13 (Packaging)

Tools

  • Docker: zchencow/innozverse-python:latest


Lab Instructions

Step 1: Registry Pattern — __init_subclass__

💡 The format= keyword in the subclass declaration is passed directly to __init_subclass__. This lets plugin authors write class MyPlugin(Base, plugin_name='my-plugin'): and automatically register without calling any registration function. The framework never needs to import plugin modules explicitly — just subclassing is enough.

📸 Verified Output:


Step 2: Hook System — Middleware Chain

📸 Verified Output:


Steps 3–8: importlib discovery, Config DSL, Versioned plugins, Dynamic routes, Dependency injection, Capstone

📸 Verified Output:


Summary

Pattern
Mechanism
Use case

Auto-registry

__init_subclass__(format=...)

Zero-config plugin registration

importlib loader

spec_from_loader + exec

Load plugins from .py files

Hook system

dict[event, list[Callable]]

Event-driven extension

Middleware chain

list[Callable], halt on flag

Request/response pipeline

DI container

dict[type, factory]

Decouple dependencies

Versioned registry

min_api comparison

Backward-compatible plugins

Further Reading

Last updated