divnix/std

The minimal template provides a standardized development stack including:

• devshell: For managing contribution environments.
• treefmt: For consistent formatting across various file types.
• mdbook: For generating and managing project documentation.
• lefthook: For managing git hooks and maintaining commit discipline.
• GitHub Setting App: For declarative GitHub configuration.

The std Cell is the primary entry point for the divnix/std repository and provides a collection of core utilities and environments. Its functionality is organized into the following components:

• TUI (Terminal User Interface): Located in ./cli.
• Devshell Profiles: Pre-configured development environments found in ./devshellProfiles.
• Library Functions: Second-level library functions located in ./lib.
• Proxied Packages: Packages used within std devshells are proxied in ./packages.

In the context of std, The Registry refers to the .#__std flake output. It contains various Registers used for discovery purposes, such as:

• CLI Discovery: Allowing the command line interface to find relevant metadata.
• CI Discovery: Allowing Continuous Integration pipelines to identify desired pipeline targets.

Standard's value is delivered through a layered approach built on top of divnix/paisano:

1. Core (Paisano): Provides the fundamental abstractions of Block Types (artifact classes with shared functionality) and Cells (organizational units).
2. Standard Block Types: A collection of specific, audited implementations of artifact types (e.g., how to build a specific type of package).
3. Standard Cells: A curated library of functions and integrations that users can adopt to implement their packaging pipelines.

This modularity allows users to benefit from optimized, audited implementations of common DevOps tasks (like pushing containers or building packages) without reinventing them locally.

The inputs argument provides access to de-systemized flake inputs and several special reserved inputs. These inputs are automatically scoped to the current system, reducing the need for manual system handling in most scenarios.

Special inputs available in the inputs set:

• self: The sourceInfo of the current repository.
• nixpkgs: An instantiated nixpkgs instance.
• cells: The other cells within the current repository.

inputs = {
  self = {};    # sourceInfo of the current repository
  nixpkgs = {}; # an _instantiated_ nixpkgs
  cells = {};   # the other cells in this repo
};

Because std avoids first-class support for fix-point logic (like global overlays) at the framework level to maintain local reasoning, users who need to apply overlays must scope them to a specific Cell Block.

When working with the Nix package collection, you can apply overlays using the appendOverlays method. Note that every time you move the fix-point via appendOverlays, it triggers a complete re-evaluation of nixpkgs, which carries a small performance penalty but preserves the project's goal of balancing productivity with ease of onboarding.

nixpkgs.appendOverlays [ /* ... */ ]

In std, Cell Blocks enforce a standardized interface to promote separation of concerns and clear contracts. When implementing a Cell Block, you must use the {inputs, cell} shape:

• cell: The local Cell context.
• inputs: The deSystemizeed flake inputs, which include:
  • inputs.self: A reference to the source code (self.sourceInfo), which can be filtered using std.incl. This is preferred over misusing the global self.
  • inputs.cells: Access to other cells by their name, providing documented boundaries.
  • inputs.nixpkgs: An instantiated nixpkgs specifically for the current system.

By using this interface, you move away from a morphing global context toward organized, predictable Nix code.