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 evo 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 evo 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 evo is on PATH and whether it is the expected evo-hq-cli package (evo --version). If the provider SDK is missing, evo'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 evo executable. If missing, ask the user before installing it.
   • If evo was installed with uv tool or pip/venv, prefer the matching extra on evo-hq-cli:
     • uv-tool: uv tool install --reinstall 'evo-hq-cli[<provider-extra>]'
     • venv / pip: python -m pip install 'evo-hq-cli[<provider-extra>]'
   • If evo was installed with pipx, inject the provider SDK into the same evo-hq-cli environment:
     • pipx: pipx inject evo-hq-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:

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