infra-setup

Infra Setup

Use this when the user wants to change where experiments run: local worktrees, pool slots, or a remote provider such as Modal, E2B, Daytona, AWS, Azure, SSH, manual, or a custom dotted-path provider.

Goals

• Be explicit about the target backend/provider.
• Check prerequisites before mutating sva config.
• Never install provider SDKs silently.
• Give one actionable auth command per provider.
• Keep provider credentials separate from benchmark runtime env.

Flow

1. Identify the target:
   • worktree or pool means local backends.
   • modal, e2b, ssh:..., or another remote spec means backend=remote.
2. If the target is remote, parse the provider choice the same way sva CLI does:

• modal
• e2b
• daytona
• aws
• azure
• manual
• ssh:user@host[:port]
  • another built-in provider name
  • dotted import path for a custom provider

1. Check whether sva is on PATH and whether it is the expected svatah-cli package (sva --version). If the provider SDK is missing, sva's provider loader prints the provider-specific extra or SDK package to install; use that message rather than guessing.
2. For SDK-backed providers, verify the SDK import only when you can run the check in the same environment that owns the sva executable. If missing, ask the user before installing it.
   • If sva was installed with uv tool or pip/venv, prefer the matching extra on svatah-cli:
     • uv-tool: uv tool install --reinstall 'svatah-cli[<provider-extra>]'
     • venv / pip: python -m pip install 'svatah-cli[<provider-extra>]'
   • If sva was installed with pipx, inject the provider SDK into the same svatah-cli environment:
     • pipx: pipx inject svatah-cli <provider-sdk>
3. Check auth and show exactly one provider-specific auth command or setup step. Use references/provider-matrix.md.
4. Once prerequisites are satisfied, run the explicit config command:

sva config backend remote --provider <provider> --provider-config ...