Skip to content

[Distribution] Install a verified Flow suite with a flow command and independent providers #71

Description

@szmyty

Suite roadmap: #11
Depends on: #53 and #70; release gate for #54
Provider prerequisites: immutable Optiflow v0.1.1 and the releases consumed by #51 and #52

Outcome

Ship a genuine installable Flow suite: one flow command, an independently usable Rust library, and an explicit, verifiable path to the Aniflow, Optiflow, and Renderflow executables used by its supported profiles. A user should be able to install, inspect provider readiness, process a synthetic local file, and uninstall/roll back without a checkout of four repositories.

Registry and architecture facts to resolve

  • Current Flow Cargo.toml declares publish = false and only a test-fixture flow-hermetic-provider binary; [FLO-3.7] Ship the supported Flow CLI and close the vertical slice #53 owns the production CLI.
  • The crates.io package name flow is already used by an unrelated project. Do not claim cargo install flow installs this suite. Verify registry ownership/availability again before choosing a publishable package name (for example, egohygiene-flow) that installs a binary named flow.
  • Keep the three holons independent. Renderflow currently declares a newer Rust MSRV than Flow, so do not solve packaging by adding mutable sibling source dependencies or claiming a single Rust toolchain builds them all.

Scope and acceptance criteria

  • Decide and document the supported distribution channels and exact commands: a verified suite bundle containing the compatible executables, and a Cargo installation channel for the Flow CLI/library if a registry name and publishing authority are available. If registry publication is unavailable, document and test the supported cargo install --git or release-binary path honestly.
  • Package only released, digest-pinned provider assets from their owners. Publish a machine-readable lock/compatibility manifest for OS/architecture, provider and CLI/schema versions, capabilities, artifact digests, licenses/notices, and toolchain constraints; do not import their source crates into Flow.
  • Make setup/discovery/doctor report installed, missing, mismatched, unsupported, and optional capabilities with precise remediation. Any provider acquisition or network access must be an explicit user-requested, integrity-checked step; ordinary inspect/plan/run stays offline-capable.
  • A fresh supported Linux, macOS, and Windows installation proves command identity, provider locks, representative local-file profile(s), missing/incompatible-provider refusal, rollback/uninstall, and independent holon executability. Mark unavailable native evidence plainly.
  • cargo package --list, package validation, binary names, install directions, SBOM/provenance, checksums/signature policy, and docs agree with the actual downloadable bits; keep the test fixture binary out of user-facing defaults.
  • The supported first release can run the read-only Optiflow route and published Renderflow/Aniflow routes without claiming unreleased mutation, codec, model, or GPU capabilities.

Non-goals

A monolithic crate that compiles sibling source trees, unreviewed third-party binaries, silent downloads, or broad optional product profiles. #54 owns the immutable Flow release publication after this packaging is proven.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions