Skip to main content

metaclass-registry

Zero-boilerplate metaclass-driven plugin registry system with lazy discovery and caching

PyPI version Documentation Status Python 3.10+ License: MIT Coverage

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 RegistryFamily and RegistryKeyAttribute
  • Registered Enums: RegisteredEnumMeta for 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.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for metaclass-registry 0.2.2
File Size Uploaded
metaclass_registry-0.2.2.tar.gz 30.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for metaclass-registry 0.2.2
File Interpreter ABI Platform
metaclass_registry-0.2.2-py3-none-any.whl Python 3 none any Details

Total release size: 53.3 kB

Release files / metaclass_registry-0.2.2.tar.gz

Download URL metaclass_registry-0.2.2.tar.gz
Size 30.8 kB
Tags Source
SHA-256 checksum
How to use checksums
540bd730c52a535e08866c487b34aa4f9cb2fe857eb07a312882cdc43a15517c
BLAKE2b-256 checksum
How to use checksums
84b95b443e9e40c5bc7b43ef1b5a0fc815590998a56a0cc3016b56bf83e6738a
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 Oct 2, 2026.

Transparency log

Release files / metaclass_registry-0.2.2-py3-none-any.whl

Download URL metaclass_registry-0.2.2-py3-none-any.whl
Size 22.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
67ae17c58d9d10cd58acf83ebe01833c1f1fe0a1a2e281924fab836958d592ed
BLAKE2b-256 checksum
How to use checksums
0ffd4b3043710035b1c21c0edb5ca24ee7bee8b5fc61a2162d93f527326ab2ed
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 Oct 2, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.2 This release

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.6

2 release files

0.1.5

2 release files

0.1.4

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page