Environments
Define the runtime contract before writing around machine-specific accidents.
Local and remote runs should differ only where the hardware genuinely differs.
Choose the smallest sufficient boundary
- uv: pure-Python robotics, ML, data, and tooling without required system
packages. Commit the lockfile and run project commands through
uv run.
- Docker: ROS 2, native libraries, apt packages, an exact Linux userspace,
or deployment as a container.
- Docker plus uv: use Docker for the system layer and a project environment
for substantial Python dependencies; do not turn the image's system Python
into an untracked package set.
- Remote GPU host: use when the workload has no viable local hardware path.
Record this as a deliberate exception to local/remote symmetry.
Preflight the actual machine before deciding. Confirm architecture, OS, Docker
daemon, accelerator, driver, disk, and available Python tooling. Use the Robium
doctor if present; fall back to direct probes when it is not.
Keep the contract reproducible
- Pin Python and dependency resolution with a lockfile, or pin the container
base and build inputs. Avoid
latest for reproducible applications.
- Keep dependency declarations in one source of truth; do not preserve manual
installation steps as hidden prerequisites.
- Match container CUDA/runtime requirements to the target host driver rather
than the developer laptop.
- Design remote work as headless first. Use web visualization instead of making
X forwarding part of the normal workflow.
- Test the same entry command in the target environment and prove important
hardware, file, device, network, and display assumptions.
Go deeper only when needed
- Pure Python and lockfiles: uv patterns.
- ROS/system images, build layout, and parity: Docker patterns.
- NVIDIA passthrough and headless operation: GPU and remote.
- Real-robot LAN, Wi-Fi, DDS/NAT, and Mac host issues: robot networking.
- Workloads that can exist only on cloud GPUs: GPU cloud,
then the relevant provider skill for provisioning.
- macOS, Apple Silicon, arm64, and cold-build evidence: platform notes.
- Use the bundled examples only as starting shapes; verify all tags and install
steps against current upstream documentation.
Cross into integration when multiple modules, containers, or transports must
be wired together. Cross into a deployment skill only after the image and
runtime contract work locally or in an equivalent target environment.
Done
- A fresh machine can reproduce the environment from committed inputs.
- The same documented command starts the workload locally and remotely, except
for named hardware flags.
- GPU, devices, network, files, and display behavior are verified on the target.
- Current details match official uv,
Docker, ROS image, and
NVIDIA Container Toolkit
documentation.
1---2name: environments3description: Set up reproducible robotics environments with uv, Docker, or GPU hosts.4---56# Environments78Define the runtime contract before writing around machine-specific accidents.9Local and remote runs should differ only where the hardware genuinely differs.1011## Choose the smallest sufficient boundary1213- **uv:** pure-Python robotics, ML, data, and tooling without required system14 packages. Commit the lockfile and run project commands through `uv run`.15- **Docker:** ROS 2, native libraries, apt packages, an exact Linux userspace,16 or deployment as a container.17- **Docker plus uv:** use Docker for the system layer and a project environment18 for substantial Python dependencies; do not turn the image's system Python19 into an untracked package set.20- **Remote GPU host:** use when the workload has no viable local hardware path.21 Record this as a deliberate exception to local/remote symmetry.2223Preflight the actual machine before deciding. Confirm architecture, OS, Docker24daemon, accelerator, driver, disk, and available Python tooling. Use the Robium25doctor if present; fall back to direct probes when it is not.2627## Keep the contract reproducible2829- Pin Python and dependency resolution with a lockfile, or pin the container30 base and build inputs. Avoid `latest` for reproducible applications.31- Keep dependency declarations in one source of truth; do not preserve manual32 installation steps as hidden prerequisites.33- Match container CUDA/runtime requirements to the target host driver rather34 than the developer laptop.35- Design remote work as headless first. Use web visualization instead of making36 X forwarding part of the normal workflow.37- Test the same entry command in the target environment and prove important38 hardware, file, device, network, and display assumptions.3940## Go deeper only when needed4142- Pure Python and lockfiles: [uv patterns](references/uv-patterns.md).43- ROS/system images, build layout, and parity: [Docker patterns](references/docker-patterns.md).44- NVIDIA passthrough and headless operation: [GPU and remote](references/gpu-and-remote.md).45- Real-robot LAN, Wi-Fi, DDS/NAT, and Mac host issues: [robot networking](references/robot-networking.md).46- Workloads that can exist only on cloud GPUs: [GPU cloud](references/gpu-cloud.md),47 then the relevant provider skill for provisioning.48- macOS, Apple Silicon, arm64, and cold-build evidence: [platform notes](PLATFORM-NOTES.md).49- Use the bundled examples only as starting shapes; verify all tags and install50 steps against current upstream documentation.5152Cross into `integration` when multiple modules, containers, or transports must53be wired together. Cross into a deployment skill only after the image and54runtime contract work locally or in an equivalent target environment.5556## Done5758- A fresh machine can reproduce the environment from committed inputs.59- The same documented command starts the workload locally and remotely, except60 for named hardware flags.61- GPU, devices, network, files, and display behavior are verified on the target.62- Current details match official [uv](https://docs.astral.sh/uv/),63 [Docker](https://docs.docker.com/), ROS image, and64 [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/)65 documentation.