lucasgelfond/zerobrew

Zerobrew is a Homebrew-compatible package manager implemented in Rust, designed to install, upgrade, and manage software formulas and casks across macOS and Linux. It provides a command-line interface for package lifecycle management, including source builds, dependency resolution, and system diagnostics, alongside a static marketing website for documentation and installation guidance.

The \zb\_core\ library has been introduced to provide the foundational components for the package manager. This includes a \Context\ struct that defines default system paths (rooted at \/opt/zerobrew\) and concurrency limits for downloads and builds. A comprehensive \Error\ enum is added to handle specific failure modes such as checksum mismatches, link conflicts, unsupported bottles, and dependency cycles. Additionally, the \formula\ module exposes types for managing formula states (like \KegOnly\) and logic for selecting compatible macOS bottles.

_zb\core/src · high confidence

This change introduces the foundational structure for the zerobrew project, including the initial release notes in CHANGELOG.md, contributor guidelines in CONTRIBUTING.md, a Code of Conduct, and a Security Policy. It also adds the primary README files (English and Chinese), dual Apache 2.0/MIT license files, a Justfile for build and test automation, and a .gitignore to exclude build artifacts and site dependencies.

(repo-wide) · high confidence

The build module now exposes a \BuildPlan\ struct and a \detect\_build\_system\ function that determines the build system (CMake, Meson, Autoconf, or RubyFormula) based on a formula's source URL and build dependencies. This enables the package manager to automatically select the correct build toolchain when generating installation plans from formula definitions.

_zb\core/src/build · high confidence

The \zb\_io\ module now includes a new \build\ submodule that enables building packages from source. This adds a \BuildExecutor\ to orchestrate the download, extraction, and execution of Ruby-based build shims, alongside an \environment\ module that configures build variables (such as \PATH\, \PKG\_CONFIG\_PATH\, and \CFLAGS\) and detects the number of available CPUs. The implementation also introduces a \source\ module for downloading and extracting source tarballs with SHA-256 verification, and a \shim.rb\ file that provides a Homebrew-compatible Ruby DSL for formula execution.

_zb\io · high confidence

The site area now serves a fully functional marketing website built with Eleventy. The homepage features a hero section, an interactive install panel with copy-to-clipboard support for bash, brew, and AUR commands, and a benchmark comparison chart. The site includes a responsive layout, semantic navigation, and redirects for /install, /discord, and /github.

site · high confidence

The \zb\ CLI now includes a comprehensive set of new commands to manage packages and system state. Users can bundle installations and configurations using \zb bundle\ (with \install\ and \dump\ subcommands) to manage Brewfile manifests. System health can be diagnosed and repaired with \zb doctor\, and stale data can be cleaned up via \zb gc\. Package updates are handled by \zb outdated\ (supporting \--quiet\, \--verbose\, and \--json\ flags) and \zb upgrade\, which also supports \--build-from-source\ and \--no-link\ options. Existing workflows are enhanced with \zb update\ to clear the API cache, \zb info\ for human-readable installation timestamps, and \zb run\ for temporary package execution with automatic environment setup. Migration from Homebrew is streamlined with \zb migrate\, and the system can be fully reset with \zb reset\. Additional utilities include \zb completion\ for shell integration, \zb list\ for installed packages, and \zb uninstall\ supporting multiple packages and an \--all\ flag.

_zb\cli/src/commands · high confidence

The \zb\ command-line interface is now available, providing a Homebrew-compatible package manager. Users can install, uninstall, and upgrade formulas and casks, including support for building from source and managing Brewfiles. The CLI includes diagnostic tools like \zb doctor\ for state repair, \zb outdated\ for checking versions, and \zb run\ for executing temporary commands. Initialization (\zb init\) handles directory setup and shell configuration, with specific safeguards for macOS Mach-O path limits. The interface supports verbose/quiet modes, configurable concurrency, and provides helpful suggestions for missing formulas.

_zb\cli/src · high confidence

The CLI entry points have been reorganized to follow the src/bin/ convention, introducing zb.rs as the main executable and zbx.rs as a dedicated wrapper for the 'run' command. The zb binary now serves as the central dispatcher for all subcommands (including init, install, bundle, uninstall, doctor, update, outdated, upgrade, and reset), handling argument parsing, logging initialization, and installer setup. The new zbx binary provides a convenient way to execute commands from installed formulas without linking them by directly invoking zb run with the provided arguments.

_zb\cli/src/bin · high confidence

The formula module now provides robust dependency resolution and platform-specific bottle selection. On macOS, bottle selection prioritizes tags matching the current OS version (e.g., Sonoma, Ventura) and architecture, falling back to compatible older versions. On Linux, it selects bottles based on architecture (arm64 or x86\_64) and includes \uses\_from\_macos\ dependencies as build dependencies where appropriate. The dependency resolver now uses an index-based topological sort to correctly order installations, detect cycles, and handle transitive closures, while also ignoring macOS-specific keg-only reasons on non-macOS platforms.

_zb\core/src/formula · high confidence

Added integration tests for the \zb\ CLI, covering \install\, \uninstall\, \list\, \info\, and \gc\ commands, as well as specific formula behaviors like \curl\ being keg-only on macOS versus linked on Linux. The test suite uses isolated temporary environments to prevent host-level configuration leaks and ensures binaries function correctly from both the linked bin directory and the cellar.

_zb\cli/tests · high confidence

This change introduces the dependency manifests for the project's Rust workspace (zb\_cli, zb\_core, zb\_io) and the Eleventy-based site build. The Rust workspace sets a Minimum Supported Rust Version (MSRV) of 1.96 and configures core libraries including tokio, serde, clap, reqwest (with rustls TLS backend), and rusqlite. The site configuration adds @11ty/eleventy for static site generation and wrangler for deployment.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 64 → 67 (+2.7)
• Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

• Code Health 83 → 83 (+0.0)
• Architecture 98 → 96 (-2.2)
• Maturity 59 → 59 (+0.0)
• Readiness 68 → 68 (+0.1)
• Security 57 → 67 (+9.7)
• Performance 100 (new)

• Critical CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• High CVE: [CVE redacted] (site/pnpm-lock.yaml)
• …and 21 more

• End-of-life runtime: Rust 1.96
• High CVE: [GHSA redacted] (site/pnpm-lock.yaml)
• High CVE: [GHSA redacted] (site/pnpm-lock.yaml)
• Inconsistent naming convention for progress variants. ParallelDownloader uses download_all_with_progress, while Downloader uses download_with_progress. While the scope differs (all vs single), the prefix with_progress is used in one and implied/absent in the other's base method. More importantly, ParallelDownloader has download_single and download_all_with_progress, but lacks a download_single_with_progress or a generic download_with_progress that handles single items, creating an asymmetry in the API surface between the two downloader implementations.
• Inconsistent return type naming and intent. get_formula likely returns a single Formula or Result<Formula>, while get_all_formulas_raw returns raw data. The naming get_all_formulas_raw is verbose and inconsistent with get_formula. If get_formula returns a parsed object, get_all_formulas should likely return a collection of parsed objects, or get_all_formulas_raw should be renamed to get_all_formulas if it returns parsed data, or get_formula_raw if it returns raw data. The current mix of 'raw' and non-'raw' suggests an inconsistency in whether the API returns parsed or raw data.
• Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
• Off the main sequence: zb_core
• Off-boarding risk: anonymized user #1
• Outdated: chrono
• Outdated: reqwest
• Signature mismatch in parameter type. download_all takes a single DownloadRequest (likely a typo for a slice or vec), while download_all_with_progress also takes a single DownloadRequest. However, the method name download_all implies multiple items, and the other method download_single takes a single item. It is highly probable that download_all should accept a collection (e.g., &[DownloadRequest]) to be consistent with the semantic intent of 'all' and to match the pattern of download_all_with_progress if it also intends to handle multiple, or if download_all_with_progress is the correct multi-item handler, download_all is ambiguous. More critically, looking at download_single, it takes a single request. If download_all is meant to take multiple, the type DownloadRequest is likely incorrect (should be a slice/vec). If it takes a single request, it is redundant with download_single but without progress, which is a minor inconsistency in naming vs utility. Given download_all_with_progress exists, download_all likely intends to be the non-progress multi-download, but the type signature DownloadRequest (singular) contradicts the name all.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

lucasgelfond/zerobrew was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.