nip — Nexus Integrated Package Manager

MVP Complete

nip is the universal package manager for Nexus OS. It handles package installation, dependency resolution, system builds, and ecosystem grafting from a single tool.

Modes of Operation

nip operates in two modes:

Host Mode

Used during development and system building. Runs on a standard Linux/macOS/BSD workstation to cross-compile and prepare packages for Nexus targets.

Sovereign Mode

Used on a running Nexus system. Manages packages, applies updates, and enforces the security pipeline.

Key Features

Universal Grafting

nip can fetch, adapt, and package software from any ecosystem:

nip graft nixpkgs::firefox     # Graft from Nix
nip graft alpine::musl         # Graft from Alpine
nip graft pkgsrc::openssh      # Graft from NetBSD pkgsrc

Each grafted package goes through the security pipeline (strip → pledge → freeze → sign).

Quarantine Pipeline

New packages enter a quarantine zone before being installed:

1. Fetch: Download and verify source integrity
2. Strip: Remove docs, debug info, unnecessary files (<5% of original size)
3. Build: Compile with Nexus toolchain (Nim + Zig)
4. Pledge: Apply security constraints from the recipe
5. Freeze: Produce a deterministic binary with a Variant-CID
6. Sign: Ed25519 signature by the build identity
7. Install: Only after all checks pass

Variant-CID

Every package build produces a unique Variant-CID — a content identifier that encodes:

• Source hash
• Build flags
• Target architecture
• Dependency versions

Two builds with the same inputs produce the same Variant-CID. Different inputs produce different CIDs. This enables reproducible builds and provenance verification.

KDL Recipes

Package definitions use KDL syntax:

package "firefox" version="120.0" {
  source url="https://..." hash="blake3:..."
  depends "musl" "mesa" "dbus"
  build {
    configure "--disable-debug" "--enable-release"
    make jobs=4
  }
  pledge "STDIO" "RPATH" "INET" "WPATH"
  unveil "/Data/users" "rw"
  unveil "/Bus/hud" "rw"
}

Registry (DuckDB)

nip uses DuckDB as its local package registry. Three tables:

Table	Purpose
packages	Package metadata, versions, CIDs
dependencies	Dependency graph
provenance	Build provenance (who built what, when, with what)

Queries use PRQL (Pipelined Relational Query Language) for semantic package searches.

Paradox Resolver

nip's dependency resolver (SPEC-113) uses a three-phase algorithm to handle dependency conflicts:

1. Expand: Build the full dependency tree
2. Detect: Find conflicts (version mismatches, circular deps)
3. Resolve: Apply resolution rules (newest compatible, USE flag selection, manual override)

AST Registry

For advanced use cases, nip includes an AST (Abstract Syntax Tree) Registry (SPEC-117) — a columnar database of parsed source code ASTs. This enables:

• Semantic search across all installed packages
• Automatic API compatibility checking
• Dead code detection