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

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

Generic runtime behavior lives in cs; opinionated package sets and distribution defaults belong in downstream projects.

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.

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 [tool.conda] is supported through conda-workspaces and uses conda.lock.

  • pixi.toml/pixi.lock and pyproject.toml with [tool.pixi] are supported for downstream projects that use Pixi for the source solve.

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

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

  • [tool.conda-ship].delegate chooses which executable receives pass-through arguments after bootstrap.

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

  • Package and channel intent comes 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 the GitHub Action intentionally lockfile-first, with package and channel changes made in committed project manifests rather than action inputs

  • add Windows ARM64 release assets only after the conda package ecosystem has enough stable win-arm64 coverage for conda-ship runtimes