didericis-claude
0efc07ba67
Closes #178. The backend provision functions now receive a Bottle handle with exec / cp_in methods instead of a raw target string. Provisioner modules use bottle.exec and bottle.cp_in in place of inlined subprocess.run(["docker", "exec"/"cp", ...]) and direct _smolvm.machine_cp / machine_exec calls. This decouples the provisioners from backend-specific runtime primitives so future refactors (e.g. the supervise rework) can swap the bottle's exec implementation without touching every provisioner. Each launch.py constructs the Bottle handle before calling provision so it can be passed in; provision_prompt's return value is wired back onto the bottle's prompt path attribute after the fact.
9 lines
365 B
Python
9 lines
365 B
Python
"""Per-provisioner modules for the Docker backend.
|
|
|
|
Each module exports one top-level function:
|
|
provision_<thing>(plan: DockerBottlePlan, bottle: Bottle) -> ...
|
|
|
|
`DockerBottleBackend.provision_*` methods delegate to these. The
|
|
abstract `BottleBackend.provision_*` surface is unchanged; this
|
|
subpackage exists only to keep `backend.py` from being a god-file."""
|