Skip to content

perf: lazy-load extension framework modules - #1208

Open
lczyk wants to merge 1 commit into
canonical:mainfrom
lczyk:perf/lazy-extensions
Open

perf: lazy-load extension framework modules#1208
lczyk wants to merge 1 commit into
canonical:mainfrom
lczyk:perf/lazy-extensions

Conversation

@lczyk

@lczyk lczyk commented May 14, 2026

Copy link
Copy Markdown

just an idea.

the extensions package eagerly imported all six framework modules at import time. for most rockcraft ... calls its not needed. i've changed the extensions to be lazy loaded (ahead of https://peps.python.org/pep-0810/ landing in 3.15)


  • I've followed the contribution guidelines.
  • I've signed the CLA.
  • I've successfully run make lint && make test.
  • I've added or updated any relevant documentation.
  • In documents I changed, I added a meta description if one was missing.
  • I've updated the relevant release notes.

the extensions package eagerly imported all six framework modules at
import time, and gunicorn pulled in the full `packaging` parser chain.
none of it is needed for an extension-free `rockcraft pack`.

register zero-arg loader callables instead of the classes themselves;
the registry resolves a loader on first `get_extension_class` and caches
the class back in its place. a module `__getattr__` keeps the
`extensions.<ClassName>` attribute access working for callers that rely
on it. framework modules are now imported only when an extension is
actually applied or listed.

warm `import rockcraft.cli` drops the `rockcraft.extensions` subtree from
~18ms to ~1-2ms and `rockcraft.commands` from ~30ms to ~12ms; on the
cold managed-instance squashfs the per-module cost scales up further.
@lczyk
lczyk requested a review from tigarmo as a code owner May 14, 2026 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant