metaclass-registry
Zero-boilerplate metaclass-driven plugin registry system with lazy discovery and caching
Features
- Zero Boilerplate: No custom metaclasses, no manual registry creation, just class attributes
- Lazy Discovery: Plugins discovered automatically on first access
- Registry Inheritance: Child classes inherit parent's registry for clean interface hierarchies
- Secondary Registries: Auto-populate related registries from primary registry
- Persistent Caching: Cache discovery results across process restarts
- Explicit Discovery: Package scans occur only when the nominal root declares them
- Host Logging Safety: Discovery imports preserve application-owned root logging
- Nominal Registry Families: Stable key-axis declarations with
RegistryFamilyandRegistryKeyAttribute - Registered Enums:
RegisteredEnumMetafor enum members backed by a nominal registry - Type-Safe: Full type hints and mypy support
Quick Start
from metaclass_registry import AutoRegisterMeta, RegistryFamily
# Define the nominal family and its semantic key axis.
class PluginBase(metaclass=AutoRegisterMeta):
__registry_family__ = RegistryFamily(
"plugin_name",
registry_name="plugin",
)
__registry__ = {} # Local script: no package discovery required.
plugin_name = None
# Access the auto-created registry
PLUGINS = PluginBase.__registry__
# Define plugins - they auto-register!
class MyPlugin(PluginBase):
plugin_name = 'my_plugin'
def run(self):
return "Hello from my plugin!"
# Use the registry
print(list(PLUGINS.keys())) # ['my_plugin']
plugin = PLUGINS['my_plugin']()
print(plugin.run()) # "Hello from my plugin!"
RegistryFamily is the preferred declaration for an ordinary nominal root.
It installs the compatibility attributes used by AutoRegisterMeta while
keeping the key axis in one object. Consumers should iterate or query
PluginBase.__registry__ rather than maintain a parallel plugin mapping.
The explicit plain registry is appropriate for this one-file example. Ordinary roots
register declarations as their modules are imported; package discovery is opt-in through
RegistryConfig.discovery_package.
Use RegistryConfig when a family needs a supplied registry, a key extractor,
lazy discovery, secondary registries, or custom logging:
from metaclass_registry import (
AutoRegisterMeta,
RegistryConfig,
make_suffix_extractor,
)
HANDLERS = {}
HANDLER_CONFIG = RegistryConfig(
registry_dict=HANDLERS,
key_attribute="handler_type",
key_extractor=make_suffix_extractor("Handler"),
skip_if_no_key=True,
registry_name="handler",
)
class Handler(metaclass=AutoRegisterMeta):
__registry_config__ = HANDLER_CONFIG
handler_type = None
class FileHandler(Handler):
pass
assert HANDLERS["file"] is FileHandler
Package discovery
Package discovery is explicit in 0.2.0. A nominal root that must discover declarations which are not otherwise imported owns that behavior directly:
from metaclass_registry import AutoRegisterMeta, LazyDiscoveryDict, RegistryConfig
class Plugin(metaclass=AutoRegisterMeta):
__registry_config__ = RegistryConfig(
registry_dict=LazyDiscoveryDict(),
key_attribute="plugin_name",
discovery_package="my_application.plugins",
discovery_recursive=False,
)
plugin_name = None
Use discovery_recursive=True only when plugin declarations live in subpackages.
Without discovery_package, the registry contains declarations imported by the
application and never scans the surrounding package implicitly.
Installation
pip install metaclass-registry
Why metaclass-registry?
Most plugin systems require boilerplate code:
Before (Traditional approach):
# Custom metaclass per registry
class PluginMeta(type):
def __new__(mcs, name, bases, namespace):
cls = super().__new__(mcs, name, bases, namespace)
if hasattr(cls, 'plugin_name') and cls.plugin_name:
PLUGINS[cls.plugin_name] = cls
return cls
# Manual registry creation
PLUGINS = {}
# Base class with custom metaclass
class PluginBase(metaclass=PluginMeta):
plugin_name = None
After (metaclass-registry):
# One nominal family declaration owns the registry protocol.
class PluginBase(metaclass=AutoRegisterMeta):
__registry_family__ = RegistryFamily("plugin_name")
plugin_name = None
# Access auto-created registry
PLUGINS = PluginBase.__registry__
Advanced Features
Registry Inheritance
class BackendBase(metaclass=AutoRegisterMeta):
__registry_family__ = RegistryFamily("backend_type")
backend_type = None
class StorageBackend(BackendBase):
pass # Inherits BackendBase.__registry__
class ReadOnlyBackend(BackendBase):
pass # Also inherits BackendBase.__registry__
# All share the SAME registry!
assert StorageBackend.__registry__ is BackendBase.__registry__
Secondary Registries
Pass SecondaryRegistry declarations through the family's authoritative
RegistryConfig. Secondary mappings are derived indexes; populate them only
through registration, never through a second manual registration path.
Custom Key Extractors
Set RegistryConfig.key_extractor when names must be derived. The extractor
receives (class_name, cls) and should return the semantic key. Prefer an
explicit family key attribute when the declaration can own the value directly.
Documentation
Full documentation available at metaclass-registry.readthedocs.io
License
MIT License - see LICENSE file for details
Contributing
Contributions are welcome through the repository and its issue tracker.
Credits
Developed by Tristan Simas as part of the OpenHCS project.
Metadata
Release files for metaclass-registry 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| metaclass_registry-0.2.1.tar.gz | 29.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| metaclass_registry-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 51.4 kB
Release files / metaclass_registry-0.2.1.tar.gz
| Download URL | metaclass_registry-0.2.1.tar.gz |
|---|---|
| Size | 29.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
96d1e76970121e1afc6cc3a90fcefc2eed8d5bf40a5eced20953ea2d0bbf5849
|
|
BLAKE2b-256 checksum How to use checksums |
f88803ec6ae94b07046603fec60f0b071f66f80fb7963dafaab2e454d94e87a8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 25, 2026.
Transparency logRelease files / metaclass_registry-0.2.1-py3-none-any.whl
| Download URL | metaclass_registry-0.2.1-py3-none-any.whl |
|---|---|
| Size | 22.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
dddfa7c04d896b72b6a24744794913db42a911e770fea6bac78a4036f2a392a4
|
|
BLAKE2b-256 checksum How to use checksums |
2eea2f7997f6695e4b8e20f3476fec2fec398a232738342cbd4bea3d44b47796
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 25, 2026.
Transparency log