docker-pixi-project-offline

Scripted process to build and verify a Pixi-managed project in Docker, then produce a portable WORKDIR/product directory for air-gapped use.

7 stars

Best use case

docker-pixi-project-offline is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Scripted process to build and verify a Pixi-managed project in Docker, then produce a portable WORKDIR/product directory for air-gapped use.

Teams using docker-pixi-project-offline should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/docker-pixi-project-offline/SKILL.md --create-dirs "https://raw.githubusercontent.com/igamenovoer/magic-context/main/skills/air-gapped/docker/docker-pixi-project-offline/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/docker-pixi-project-offline/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How docker-pixi-project-offline Compares

Feature / Agentdocker-pixi-project-offlineStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Scripted process to build and verify a Pixi-managed project in Docker, then produce a portable WORKDIR/product directory for air-gapped use.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Docker Pixi Project Offline

Prepare an existing Pixi-managed project for an air-gapped environment by:
1) building and verifying it inside a Docker container (with network access), and
2) producing a **WORKDIR/product/** folder that can be packed and delivered.

This skill includes helper scripts under `scripts/`. Prefer using them (each supports `--help`) rather than retyping the manual steps.

## What to ask the user

- Project source (pick one):
  - `PROJECT_DIR`: path to the Pixi project on the host (`pixi.toml` or `pyproject.toml`), or
  - `PROJECT_PATH_IN_CONTAINER`: path to the Pixi project already present inside a container
- `VERIFY_SPEC`: one of:
  - a concrete command to run under Pixi (e.g. `python -m yourpkg --help`)
  - a Pixi task name from the manifest (e.g. `smoke`)
  - a script path (e.g. `./scripts/smoke.sh`) plus what counts as success
  - a short description of what “success” means (you convert it into one or more commands)
- Build execution target (pick one):
  - `IMAGE`: a Docker image that contains Pixi (recommended), or
  - `CONTAINER_ID`: an already-running container to use
- Optional `RESOURCES_DIR`: any extra runtime resources to bundle alongside the project (models, data files, binaries)
- Optional `CONTAINER_WORKDIR_PATH`: where the scripts stage files inside the container (use this if `/workdir` already exists or is reserved in the image/container)
- Optional `WORKDIR` (host output dir): where the scripts write the generated workdir on the host (default: `<workspace>/tmp/workdir-<ts>`)

## Preconditions

- Build machine has Docker and internet access.
- Use the provided Docker image/container. If it can run the project offline once packaged, that’s sufficient.
- Pixi is available inside the container (prebuilt image, or installed during image build).
- Air-gapped runtime must also have Pixi available (the product does not include the Pixi binary).
- For reproducibility: `pixi.lock` exists and is up to date.

## Outputs

- `WORKDIR/`: a self-contained workspace holding the staged project, resources, Pixi cache, and logs/test outputs.
- `WORKDIR/product/`: the deliverable directory (you pack and ship this folder; archiving is out of scope for this skill).

## Workdir layout

Use a single work directory so “inputs + outputs” are easy to copy/inspect:

- `WORKDIR/project/<project_name>/`: staged project copy (input to product generation)
- `WORKDIR/resources/`: optional resources to include (input to product generation)
- `WORKDIR/pixi-cache/`: Pixi cache produced during the online build (input to product generation)
- `WORKDIR/out/`: logs and test outputs only
- `WORKDIR/helpers/`: helper scripts used during preparation (not shipped to air-gapped)
  - `WORKDIR/helpers/make-archive-ready-product.sh`: creates/overwrites `WORKDIR/product/`
- `WORKDIR/product/`: generated deliverable (created/overwritten by `WORKDIR/helpers/make-archive-ready-product.sh`)

## Product layout (deliverable)

`WORKDIR/product/` must be self-contained and include:

- `WORKDIR/product/<project_name>/`: project directory containing Pixi manifest (`pixi.toml` or `pyproject.toml`) and the minimal files needed to run
- `WORKDIR/product/res/` (optional): binary data/resources required at runtime
- `WORKDIR/product/pkg-cache/`: Pixi package cache containing everything needed to install without internet
- `WORKDIR/product/envs.sh`: manual environment setup (users can `source envs.sh` before running Pixi commands)
- `WORKDIR/product/bootstrap-project.sh`: bootstraps the project (sources `envs.sh` then runs `pixi install` for `<project_name>/` using `pkg-cache/`)

## Process

### 0) Scripts

All scripts are in this skill directory:
- `scripts/create-workdir-from-host.sh`
- `scripts/create-workdir-from-container.sh`
- `scripts/make-archive-ready-product.sh`
- `scripts/final-verify-product.sh`

Each script is intended to be manually invokable and provides `--help`.
The `create-workdir-*` scripts also copy `scripts/make-archive-ready-product.sh` into `WORKDIR/helpers/` for portability.

### 1) Decide what “verification” means

Acceptable forms:
- **Pixi task**: `smoke` (run as `pixi run smoke`)
- **Script**: `./scripts/smoke.sh` (define success: exit code 0, expected output, created files, etc.)
- **Command**: `python -c "import yourpkg; print('ok')"`
- **Description**: “Running the CLI help works and prints version” (convert into one or more commands)

When executing, capture output into `WORKDIR/out/` so the workdir contains the proof.

### 2) Create `WORKDIR/`

Use exactly one of the following paths:

#### 2a) From a host project dir (recommended)

This stages a filtered copy of the project into `WORKDIR/project/<project_name>/`, runs `pixi install`, and runs verification (optional):

```bash
./scripts/create-workdir-from-host.sh --help
./scripts/create-workdir-from-host.sh \
  --image your-pixi-image:tag \
  --project-dir /path/to/project \
  --resources-dir /path/to/resources \
  --container-workdir-path /tmp/workdir \
  --verify-run -- python -c 'import yourpkg; print("ok")'
```

#### 2b) From an existing container project dir

If the project directory already exists in a running container, create `/workdir` in that container and copy it back to the host:

```bash
./scripts/create-workdir-from-container.sh --help
./scripts/create-workdir-from-container.sh \
  --container-id <CONTAINER_ID> \
  --project-path-in-container /path/to/project \
  --container-workdir-path /tmp/workdir \
  --verify-task smoke
```

### 3) Create the deliverable `WORKDIR/product/`

```bash
./tmp/pixi-offline-work/helpers/make-archive-ready-product.sh --help
./tmp/pixi-offline-work/helpers/make-archive-ready-product.sh \
  --workdir ./tmp/pixi-offline-work --project-name <project_name>
```

### 4) Final verification (offline product)

Verify the **product** (not the staged project) in an offline/no-network container. This is the final verification step.
```bash
./scripts/final-verify-product.sh --help
./scripts/final-verify-product.sh \
  --image your-pixi-image:tag \
  --product-dir ./tmp/pixi-offline-work/product \
  --out-dir ./tmp/pixi-offline-work/out \
  --project-name <project_name> \
  --verify-run -- python -c 'import yourpkg; print("ok")'
```

If this passes with networking disabled, it demonstrates that `pixi install` is satisfied by `product/pkg-cache/`.

After `WORKDIR/product/` is created and verified, the remaining steps (packing, transferring, extracting, and running in the air-gapped environment) are the user’s responsibility.

## Pitfalls / Notes

- **Offline meaning**: if “offline” means “no network”, prove it by running `./bootstrap-project.sh` and then `pixi run ...` with `--network none`.
- **Secrets**: staging matters—don’t accidentally package `.env`, credentials, SSH keys, or tokens.
- **Multiple Pixi envs**: verify/package the environment(s) you actually need.

## Future automation (not implemented here)

When you want this to be push-button, add a small orchestrator that:
- stages with consistent excludes
- runs the container build/verify
- emits a manifest (image digest, pixi version, lockfile hash)
- wraps the `scripts/` in a single command

Related Skills

pixi-make-offline-channel

7
from igamenovoer/magic-context

Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi.

pixi-make-cu-build-env

7
from igamenovoer/magic-context

Guides the agent to setup a new or existing Pixi environment for compiling C++ and CUDA code. It ensures the correct compilers, toolkits, and CMake configurations are in place for a robust user-space build.

pixi-install-nvidia

7
from igamenovoer/magic-context

Use when the user says "use pixi to install <some nvidia tool>" (or similar) and wants NVIDIA/CUDA/GPU packages installed via Pixi (no sudo/apt), e.g., CUDA toolkit pieces, cuDNN/NCCL, PyTorch CUDA builds, RAPIDS.

pei-docker-usage

7
from igamenovoer/magic-context

Helper for PeiDocker (`pei-docker-cli`). Trigger ONLY when the user explicitly requests PeiDocker usage OR when working within a PeiDocker-generated project (indicated by `user_config.yml`).

init-pixi-project

7
from igamenovoer/magic-context

Initialize and scaffold a new Pixi-managed Python project, or upgrade an existing one. Use when the user explicitly mentions "init", "initialize", or "setup" in conjunction with "pixi". Handles existing projects by prompting for confirmation before merging.

vscode-make-offline-installer

7
from igamenovoer/magic-context

Build a VS Code air-gapped "offline kit" for Remote-SSH: desktop VS Code installers/archives for Windows/macOS/Linux, matching VS Code Server+CLI tarballs for headless Linux (commit-aligned), and pinned extension .vsix bundles for both local (client) and remote (server) sides. Use when you need a reproducible offline deployment, or when you want to mirror the VS Code release+extensions currently installed on a host.

conan-basic-usage

7
from igamenovoer/magic-context

Basic operations for the Conan C++ package manager. Use when the user explicitly asks to 'use conan' for tasks like creating projects, installing dependencies, or building packages, or asks for 'how to' guidance on Conan setup.

explore-dnn-model

7
from igamenovoer/magic-context

Manual invocation only; use only when the user explicitly requests `explore-dnn-model` by name. Explore how to run a given DNN model checkpoint in the current Python environment by locating weights + upstream source code, resolving dependencies with user confirmation, running reproducible experiments under `tmp/`, and producing reports about I/O contracts, timing, and profiling.

openspec-ext-revise-by-decision

7
from igamenovoer/magic-context

Manual invocation only; use only when the user explicitly requests `openspec-ext-revise-by-decision` by exact name. Revise OpenSpec change artifacts from a review or decision document that contains questions plus `DECISION` blocks, applying chosen decisions from a review file such as `openspec/changes/<change>/review/review-*.md` back into proposal, design, specs, and tasks.

openspec-ext-review-plan

7
from igamenovoer/magic-context

Review an OpenSpec change (or a single OpenSpec change artifact file) for completeness, coherence, and alignment with existing system design; capture actionable feedback plus open questions; write a review report under the change directory (review/review-YYYYMMDD-HHMMSS.md).

openspec-ext-respond-to-review

7
from igamenovoer/magic-context

Read an OpenSpec review report critically, evaluate the reviewer's proposals and findings against the current change artifacts and repository context, and write developer-owned final decisions/responses back into the review document. Use when the user explicitly mentions `openspec` or points to a path under `openspec/` while asking to examine a review report carefully, decide open questions, respond to findings, fill `DECISION` blocks, respond to an OpenSpec review file, or record final answers in an OpenSpec review document without yet revising the proposal, design, specs, or tasks.

openspec-ext-hack-through-test

7
from igamenovoer/magic-context

Manual invocation only. OpenSpec-specific hack-through-testing workflow targeting production-level end-to-end paths using real data and real user workflows — not CI smoke/unit/integration tests. Three subskills: `propose` to create an OpenSpec change with HTT-ready test cases (automatic scripts and interactive guides) by invoking `openspec-propose` or `openspec-ff-change`, `revise` to update an existing OpenSpec change so its artifacts support hack-through-testing-driven implementation and testing, and `run` to exercise an implemented OpenSpec change through the full hack-through-testing loop (in-place by default, or in a disposable snapshot worktree when requested). Use when the user explicitly asks for `openspec-ext-hack-through-test`, points to `openspec/changes/...` while asking to propose, revise, run, exercise, or prepare work under hack-through-testing principles, or wants OpenSpec work shaped for fast blocker discovery through patch-forward testing.