perf: lazy-load backend modules and consolidate docker subprocess helpers #383
Reference in New Issue
Block a user
Delete Branch "lazy-backend-imports"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #359.
Summary
backend/__init__.pypreviously imported all three concrete backends at module load time, causingbackend.docker.utilto drag in ~76 modules (firecracker, macOS container, manifest, egress, git-gate, supervise, workspace). This PR makes those imports lazy via_get_backends()and module-level__getattr__, so they only run when a backend is first used.backend/docker/util.pysubprocess helpers (runsc_available,image_exists,container_exists,force_remove_container,commit_container) now go through the sharedrun_dockerprimitive instead of rawsubprocess.runcalls, removing the local_silent_runshim.# pylint: disableannotations for the two false positives the lazy pattern introduces (global-statementon the singleton setter,undefined-all-variableon__all__entries exposed via__getattr__).didericis-claude referenced this pull request2026-07-14 04:38:57 -04:00
b05775b581to985e79bd8eLooks good. I found no correctness issues in the lazy backend loading or the Docker subprocess-helper consolidation. Package-level compatibility is preserved through getattr, and the migrated Docker calls retain their intended return-code/error handling.
Validated locally: focused backend-selection and Docker-util tests pass (19/19), and importing bot_bottle.backend no longer loads the concrete backend modules. The current red lint/unit checks appear unrelated to this change: both runners fail during dependency installation with PEP 668 externally-managed-environment errors; integration and coverage are green.
985e79bd8eto78d72264c878d72264c8to8a321770dd