Roadmap#

cs is focused on the generic build system for single-binary conda runtimes.

The builder CLI covers the core local workflow:

  • cs inspect: preflight the selected manifest, lockfile, source environment, exclusions, and package set

  • cs build: stage an online, external, or embedded runtime

  • cs run: build and execute a local runtime for smoke testing

  • cs package-update: wrap one finalized runtime executable in a native update package

Every staged build writes the runtime plus artifact metadata: the runtime lock, a package list, a CycloneDX SBOM, an info JSON file, and SHA256 checksums. cs build --dry-run validates planned artifact work without writing files.

Generated runtime behavior lives in cs-template. This includes automatic bootstrap and executable updates when the runtime has update configuration. Downstream projects choose their own package sets and distribution defaults.

The repository stays focused on producing runtimes. Distribution wrappers such as Homebrew formulae, constructor-based installers, Docker images, or enterprise package manager recipes live outside the core builder.

Experimental Fleet API#

Fleet is an experimental Rust API. The Cargo feature that enables it is fleet. It lets orchestrators manage multiple locked conda prefixes while reusing conda-ship package installation, metadata, offline bundle code, shared package cache, prefix mutation locking, and interrupted-install recovery. Stamped runtime artifacts remain the primary conda-ship output.

The API installs, lists, inspects, and removes prefixes using locks supplied by the caller. It also returns command and shim plans. Callers provide their own catalog, solver, launchers, shell setup, and update or repair workflows.

See fleet concepts and the API reference.

Manifest And Plugin Work#

conda-ship supports conda-workspaces project input for downstream distribution builds:

  • conda.toml is the primary conda-workspaces manifest.

  • conda.lock is the matching source lockfile.

  • pyproject.toml with nonempty [tool.conda.workspace] uses conda.lock.

  • pixi.toml or pyproject.toml with nonempty [tool.pixi.workspace] uses pixi.lock.

  • [tool.conda-ship].source-environment chooses which solved environment becomes the runtime.

  • [tool.conda-ship].runtime-name names the generated runtime.

  • [tool.conda-ship].delegate-executable chooses which executable receives every argument after automatic bootstrap.

  • [tool.conda-ship].exclude-packages records post-solve pruning policy.

  • Package and channel settings come from conda workspace sections when conda.toml is available.

  • conda-ship provides a conda ship adapter while preserving cs as the primary CLI.

The packaged builder path now uses release-published runtime templates, so installed cs build and conda ship build can stamp downstream runtimes without a conda-ship source checkout.

Current follow-up work is mostly distribution hardening:

  • add richer provenance examples for package-manager specific release workflows

  • keep builds based on committed manifests and lockfiles, with package and channel changes made in the manifest

  • keep full Windows ARM64 conda runtime bootstrap coverage behind the regular canary until the conda package ecosystem has enough stable win-arm64 runtime coverage