The Minimal software supply chain

To enable declarative, reproducible & understandable software in Minimal, all software exists within a layered model we refer to as the software supply chain.

The lowest layer of the software supply chain is your repository, within which you invoke commands in the minimal CLI. Each layer depends on configuration & software in the layer above it, which is configured with an [upstream] in each layers' minimal.toml file:

[upstream]
repo = "<git remote URL>"
branch = "<git branch>"
locked_commit = "<git commit hash the repo is currently pinned to>"

TODO: Diagram

The most common upstream is our public packages registry:

[upstream] # Source of software & tooling
repo = "https://github.com/gominimal/pkgs"
branch = "main"
# locked_commit is set after the first `minimal update`

Layers in your supply chain separate concerns

TODO

Software is configuration

Software in any real environment is more complicated than binaries copied to disk, and the Minimal ecosystem represents them as such.

A piece of software is encapsulated in a package, defined at any layer of the software supply chain and usable by packages at that layer or below. Packages themselves are defined by build specifications, config-as-code that describes detailed semantics of what the software needs to function as well as an exact+reproducible description of how to build the software.

Dependencies of packages are references to other packages, an approach that enables Minimal to build exact production & development environments from simple, composable descriptions of individual packages.

For readers familiar with Nix/Nixpkgs, package build-specs are similar to Nix derivations.

Everything is (composable) configuration

In addition to declaring packages, each software supply chain layer also declares profiles & harnesses. TODO Explain powerful composition ra ra ra