compute-env-setup

• .catalog_stampruns · 13 bytes
• SKILL.mdcore · 17,812 bytes
• SKILL.mdcore · 17,812 bytes
• SKILL.mdcore · 17,812 bytes
• SKILL.mdcore · 17,812 bytes
• SKILL.mdcore · 17,812 bytes
• references/envs_reference.mdruns · 18,249 bytes

# Setting up compute environments on a remote provider

## Overview

What's invariant across every backend is what a job *needs*: a software stack (specific package versions, often with load-bearing install ordering), possibly some large model weights placed where the tool will find them, and a resource shape. What varies — a lot — is how a given provider materialises those three things and how an env name gets resolved to them at submit time. This skill is about keeping one declarative spec that says *what* the environment is, and treating *how it gets built and addressed on this provider* as something you figure out once per provider. The work ranges from minutes (another conda env on a host that has ten) to days (GPU image + weight cache + egress on a fresh backend), and most of the long tail is diagnosing why the documented invocation doesn't work even though every import succeeds.

**Before building anything:** `compute_details({provider, mode:"read"})`. The env, or a near-match you can extend, may already exist. The doc you get back is also where you'll record what you set up.

## Provider shapes

These are not exhaustive and they blend at the edges (a Slurm node can run Apptainer containers built from the same Dockerfile a cloud backend uses). The point is to recognise which shape you're in, because that determines what "build", "register", and "resolve" mean.

**Direct SSH host (conda or venv).** You have a shell on the machine. There is no image, no runner script, no renderer — *you* are the renderer: read the spec's `pip_phases` and run them in order after `conda create -n <name> python=<X>`. (When the spec's `base` is a Docker image string, treat it as documentation of the python + CUDA versions you need, not something to pull.) Weights live in scratch or home; download once, point the tool's cache env var there. The env name *is* the conda env name — name it exactly what you want `--env` to accept, there's no aliasing layer. `submit_job` activates it (`conda run -n <name> …`) and runs. "Registering" is implicit: once the host is added as a Claude Science SSH provider, its probe lists conda envs, and you append a `### env:` block to `compute_details` so the next agent knows what's there without re-probing. Lowest ceremony; often right for a personal GPU box.