nix-diff is a Haskell-based CLI tool that compares two Nix derivations (.drv files) or store paths and explains why they differ. It provides both human-readable and JSON output formats, with options to control the diff granularity (word/line/character oriented), limit context, and apply transformations to simplify large diffs. The architecture separates concerns into core diff logic (src/Nix/Diff.hs), data types (Types.hs), diff simplification transformations (Transformations.hs), store abstraction (Store.hs), and rendering (Render/HumanReadable.hs). The tool uses memoization to avoid redundant comparisons and handles relocated Nix stores via the NIX_REMOTE environment variable.
nix-doom-emacs-unstraightened is a Nix-based build system for Doom Emacs that bypasses straight.el by using Doom's CLI to export dependencies and then building them with Nix's emacsWithPackages. It provides a flake, overlay, Home Manager module, and a set of Nix expressions to build a fully reproducible Doom Emacs configuration with all dependencies pinned via Nix. The architecture consists of multiple steps: extracting package requirements from Doom via a Elisp script, applying Doom's pins to emacs-overlay packages, handling missing packages with IFD-based dependency detection, generating a Doom profile and profile loader, and finally wrapping the Emacs binary. The project features extensive CI/CD, automated daily flake updates, and a Cachix cache. It demonstrates sophisticated Nix patterns including IFD, fetchTree, structured overrides, and Emacs Lisp scripting within Nix builds.
This repository is a community distribution and feature-extension framework for OpenAI's ChatGPT desktop application on Linux. It does not contain the core ChatGPT application itself; instead, it verifies, repackages, and patches the official signed upstream .deb package to produce customized builds for multiple Linux package formats (deb, RPM, pacman, AppImage, Nix, Gentoo ebuild). The system adds over 40 optional Linux-specific features—such as system tray integration, global dictation, computer-use automation (window management, accessibility, screenshots), desktop recording/replay, text-to-speech, proxy authentication, and UI tweaks—each gated behind a declarative feature manifest and applied via a sophisticated patch engine that modifies the Electron app bundle at build time. Architecturally, the project is a build/packaging/update framework. The core is a patch engine (scripts/patches/) that applies declarative descriptors to the upstream app.asar in phases (main-bundle, webview-asset, extracted-app). Features live under linux-features/ with standardized manifests (feature.json), patch scripts (patch.js), stage hooks, and tests. Performance-critical subsystems are implemented in Rust: a computer-use backend (window management, input simulation, accessibility tree), a record-replay backend (desktop session capture, timeline events, skill drafting), a text-to-speech MCP server, a global dictation helper, and a self-updating package manager daemon. The launcher (start.sh.template) orchestrates environment setup, feature hooks, and CLI dispatch. Key entry points include the installer (install.sh), the feature picker GUI (scripts/feature-picker.py), the patch runner (scripts/patches/runner.js), and the updater daemon (updater/src/main.rs). Data flows are primarily build-time: the upstream .deb is downloaded, verified via GPG/SHA256, extracted, patched, and repackaged. At runtime, features like computer-use and record-replay communicate with native Rust backends over MCP/JSON-RPC. The updater daemon runs as a systemd user service, polling signed APT metadata and performing transactional rebuilds with rollback support. External dependencies include the upstream OpenAI .deb package (the sole ground-truth source), Node.js for patching, Rust for native components, and various Linux system tools (systemd, D-Bus, GNOME Shell, X11/Wayland utilities, ydotool, wmctrl, xdotool, secret-tool). The build system uses Make, Docker for CI, and supports multiple package managers. The project is heavily dependent on the upstream bundle's minified JavaScript structure, which it manages through contract-based patching with drift detection.
Naersk is a Nix library that automates building Rust projects by parsing `Cargo.lock` and creating Nix derivations for dependencies and the final binary. It leverages Nix's sandboxing and caching to achieve reproducible and incremental builds. The library exposes a single entry point, `buildPackage`, which accepts a source directory (or attribute set) and returns a derivation. Internally, it implements a two-phase build: first compiling all dependencies into a cached derivation, then compiling the user's crate with those pre-built dependencies. This architecture optimizes rebuild times when only the application code changes. Key capabilities include support for git dependencies, workspace crates, custom `rustc`/`cargo` toolchains, cross-compilation (via `CARGO_BUILD_TARGET`), and automatic crate-specific overrides (e.g., adding `openssl` and `pkg-config` for the `openssl-sys` crate). The codebase is implemented entirely in pure Nix, showcasing advanced Nix patterns like recursive toml serialization, generic closure traversal, and dynamic source stub generation. The project is actively maintained, has a comprehensive test suite (fast and slow), and is widely used in the Nix ecosystem.
nix-topology is a NixOS-based tool that automatically generates infrastructure and network diagrams as SVGs from NixOS configurations. It uses a global topology module to aggregate information from multiple NixOS hosts, extracting data about interfaces, services, containers, and virtual machines via specialized extractors. The gathered topology is then rendered using ELK for layout and converted to SVG via custom tools (elk-to-svg and html-to-svg), producing both a physical connection diagram (showing nodes as cards with hardware and service details) and a network-centric view (showing logical networks and their connections). The architecture is modular, with clear separation between information gathering, topology aggregation, and rendering.
Nixpkgs is the largest, most comprehensive package repository for the Nix package manager and the NixOS Linux distribution. It contains over 140,000 package definitions spanning virtually every domain of software, along with the build infrastructure, standard environment, and NixOS system modules needed to build and configure a complete operating system declaratively. The repository is not a single application but a collection of Nix expressions, shell scripts, Python tools, and Rust utilities that together form a reproducible, source-based distribution framework. It provides a modular module system for declarative configuration, a generic build phase hook mechanism, extensive CI automation for PR review and package updates, and a sophisticated test driver for integration testing. The codebase is actively maintained with thousands of contributors, and its architecture emphasizes composability, reproducibility, and cross-platform support.
SrvOS is a production-grade NixOS and nix-darwin configuration framework that provides opinionated, modular server configurations. The codebase exports NixOS modules organized into machine types (common, server, desktop), hardware profiles (Hetzner, AWS, DigitalOcean, Vultr), roles (GitHub Actions runner, Nix remote builder), and mixins (telegraf, nginx, terminfo). It uses Nix flakes for dependency management and includes comprehensive test configurations that validate module evaluation across multiple platforms. The architecture follows NixOS module patterns with clear separation between shared configurations, platform-specific modules, and role-based configurations. Key entry points are default.nix and flake.nix, which expose nixosModules and darwinModules for consumption. The codebase demonstrates strong engineering practices with security-focused defaults (SSH hardening, sudo restrictions), comprehensive systemd service configurations, and production-ready monitoring setups. Notable for its GitHub Actions runner implementation, which includes sophisticated token management via GitHub Apps, ephemeral runner support, and secure systemd sandboxing. The Prometheus alert rules provide production monitoring capabilities with well-defined alert conditions for infrastructure health.
Blitzar is a high-performance C++ library for GPU-accelerated cryptographic zero-knowledge proofs, developed by Space and Time. It provides multi-scalar multiplication (MSM), Pedersen commitments, inner product arguments, sumcheck proofs, and sequential commitments over multiple elliptic curves (Curve25519/Ristretto255, BLS12-381, BN254, Grumpkin). The library supports both CPU and CUDA GPU backends, with a stable C API and Rust bindings (blitzar-sys). It is designed for use in Space and Time's Proof of SQL, enabling analytic queries on large datasets with sub-second proof generation. The codebase is well-structured with extensive unit tests, benchmarks, and a Bazel/Nix build system. It incorporates optimized algorithms (Pippenger, bucket methods) and low-level field/curve arithmetic adopted from libsodium and zkcrypto, demonstrating strong engineering craftsmanship in GPU cryptography.
NUR (Nix User Repository) is a community package registry and distribution layer for Nix. In production it maintains a registry of several hundred user-contributed Nix repositories in repos.json, pins every entry to a specific revision in repos.json.lock, and exposes the aggregate as a Nix flake/overlay/package set. The Nix entry points (default.nix, flake.nix, lib/evalRepo.nix, lib/repoSource.nix) lazily translate locked registry entries into `nur.repos.<name>.<pkg>` attributes, including typed support for NixOS, Home Manager, Darwin, and flake-parts modules and overlays via flake-parts. The operational core is a small, typed Python CLI (`bin/nur` and `ci/nur/`) with subcommands for updating the lockfile, evaluating repos, formatting the manifest, generating a combined monorepo, and producing a search index. Updates run hourly via GitHub Actions: each repo is concurrently prefetched using either the Git smart HTTP protocol or GitHub/GitLab archive endpoints, evaluated in a sandboxed `nix-env` run to catch breakage, and then either locked to a new revision or pruned from the registry if deleted. A separate set of CI scripts publishes `nur-combined` and updates package search data. The architecture is cleanly split between Nix expression logic and Python automation, with careful handling of async concurrency, evaluation failures, and safety guards against accidental mass repository loss.
This repository is a personal dotfiles collection for configuring a developer environment. It provides a cohesive setup across Linux distributions using Nix flakes and Home Manager for declarative configuration, with fallback scripts for other systems. The environment integrates Zsh shell, Neovim editor, terminal emulators (Wezterm/Alacritty), and window managers (i3/Sway) with consistent keybindings and productivity enhancements. Configuration is modular, with isolated plugin setups for Neovim and Zsh, utility scripts for cross-tool functionality, and version management via mise. The repository emphasizes reproducibility through lock files and structured installation processes.
Kubenix is a Nix-based framework for declarative Kubernetes management. It uses the NixOS module system to define Kubernetes resources, Helm charts, Docker images, and custom resources in a type-safe, composable manner. The project provides a CLI tool for applying manifests with diffing, pruning, and secret injection via vals. At its core, kubenix is a set of Nix library functions and modules that evaluate user configuration to produce Kubernetes YAML/JSON. It supports submodules (nested composable configurations), testing frameworks (including kubetest), and code generation from Kubernetes OpenAPI specs. The architecture is purely functional, leveraging Nix's lazy evaluation to merge and validate resources at build time. This is a hybrid project combining a library (Nix modules and functions) with an application (CLI tool), but it is classified as an application because its primary deliverable is a deployable package and CLI.
TeslaMate is a self-hosted data logger for Tesla vehicles that collects telemetry via the Tesla API (both polling and streaming), stores data in PostgreSQL, and provides visualization through a Phoenix LiveView web interface and Grafana dashboards. It integrates with home automation systems via MQTT and supports importing historical vehicle data from CSV files (TeslaFi format). The application uses a supervision tree to manage background processes for data collection, MQTT publishing, import tasks, and update checking. Key features include geofencing for location-based cost tracking, encrypted storage for API tokens using Cloak, internationalization via Gettext, and custom Ecto expressions for geographic calculations. The architecture is monolithic with clear separation of concerns through Phoenix contexts (Log, Vehicles, Settings, Locations).
This repository is a personal Nix configuration (dotfiles) for managing a heterogeneous fleet of machines: NixOS desktops and servers, macOS laptops (via nix-darwin), and Kubernetes clusters (k3s, KubeVirt). It is structured as a Nix flake with modular components for system configuration, home-manager profiles, package overlays, secrets management (agenix), and infrastructure monitoring (Grafana, Prometheus, VictoriaMetrics, Loki). The codebase demonstrates advanced Nix patterns: parameterized module generators for K3s and KubeVirt, automatic file scanning for module imports, declarative disk partitioning (disko), ephemeral root filesystems with persistent state (preservation), and sandboxed GUI applications (nixpak, bwrap). It also includes a custom desktop shell (noctalia) and extensive input method customization (Rime/Fcitx5). While highly personalized and not intended for direct reuse, the architectural patterns and modular design serve as a reference for building complex Nix-based infrastructure. The repository is actively maintained with eval tests and CI, but lacks integration tests for runtime services.
Union is a hyper-efficient zero-knowledge infrastructure layer for cross-chain interoperability, implementing IBC (Inter-Blockchain Communication) with light clients for Cosmos, Ethereum, Sui, StarkNet, Gno, and many other chains. The system comprises a Cosmos SDK blockchain (uniond), a zero-knowledge prover (galoisd) for Groth16 proofs, a modular relayer (voyager) with plugin-based architecture, CosmWasm smart contracts for IBC and asset transfers (UCS03), EVM Solidity contracts, and a TypeScript SDK for programmatic interaction. The frontend is a Svelte 5 application (app2) providing a transfer interface, explorer, dashboard, and staking UI, while documentation is served via an Astro site. The architecture is a multi-language monorepo with Rust as the dominant language for core libraries and relayer modules, Go for the Cosmos SDK chain and prover, TypeScript for SDKs and frontend, and Solidity/Move for smart contracts. Key design patterns include a trait-based light client interface (IbcClient), a plugin system for relayer modules (voyager_sdk), functional effect management in TypeScript (Effect-TS), and derive macros for encoding (model, ssz, ethabi). The codebase demonstrates high craftsmanship in its type-safe encoding primitives, storage abstractions (depolama), and persistent queue (pg-queue), though it suffers from some code duplication across SDK versions and generated protobuf drift risks.
Xonsh is a cross-platform, Python-powered interactive shell that combines Python syntax with shell subprocess commands. The codebase implements a full shell environment with a custom parser (PLY-based with version-specific extensions), an execution engine that compiles xonsh code to Python AST, a rich tab-completion system with multiple backends (bash, git, pip, python, custom completers), a pluggable history backend (JSON, SQLite), a prompt system with git status and virtualenv information, and a subprocess management layer with job control. It also includes CLI tools for formatting, linting, and interactive configuration (xonfig wizard and web UI). The architecture is monolithic with a clear module structure: parsers, executers, completers, prompts, history, procs, and shells. External dependencies include prompt_toolkit, pygments, and PLY (vendored). The repository is actively maintained with frequent releases, supports Python 3.10+, and has an extensive test suite. Some technical drift exists due to deprecated API shims, multiple parser versions, and LLM-generated tests, but the core is well-engineered.
OpenClaw is a Nix flake that packages the OpenClaw AI assistant gateway for declarative installation on NixOS, macOS, and Home Manager. It provides a Home Manager module (programs.openclaw) and a NixOS module (services.openclaw-gateway) with options for instances, plugins, skills, workspace files, environment variables, and systemd/launchd services. The flake also includes an overlay, a Home Manager module for runtime plugins, and a set of Nix scripts that generate and validate plugin locks, config options, and runtime plugin materialization.
This repository provides reproducible Nix packaging for a collection of CLI tools (summarize, discrawl, wacrawl, gogcli, goplaces, camsnap, sonoscli, peekaboo, poltergeist, sag, imsg, qmd) used in the OpenClaw ecosystem. It includes per-tool OpenClaw plugin metadata (skills) that teach AI agents how to use each tool. The repo features automated update workflows: a Go-based tool updater (`cmd/update-tools`) that fetches latest GitHub releases and updates Nix expressions with new versions and hashes, and a skill syncer (`cmd/sync-skills`) that pulls the latest skill definitions from upstream OpenClaw repositories. The Go code demonstrates solid engineering with proper timeout handling, process group management, atomic file updates, and comprehensive tests. The Nix expressions are well-structured, supporting multiple platforms (aarch64-darwin, x86_64-linux, aarch64-linux) and using pinned nixpkgs inputs for reproducibility. CI runs formatting checks, vetting, tests with race detector, and builds all packages on supported systems. The repository is actively maintained with frequent commits and automated CI runs.
Attic is a self-hostable Nix binary cache server written in Rust. It provides a multi-tenant, globally deduplicated cache for Nix store paths, supporting both local filesystem and S3-compatible storage backends. The system consists of a server binary (`atticd`) that implements the Nix binary cache HTTP API and a client CLI (`attic`) for authentication, pushing store paths, and managing caches. Authentication is stateless via signed JWTs (RS256/HS256) with fine-grained permissions per cache. The server uses content-defined chunking (FastCDC) to split NAR archives into variable-sized chunks, enabling deduplication at both the NAR and chunk levels. Compression (brotli, zstd, xz) is applied during upload with simultaneous hash computation for integrity verification. Garbage collection supports per-cache retention periods and cascading deletion from local caches to global chunk storage. The codebase is organized as a Cargo workspace with four crates: `attic` (core library with chunking, hashing, Nix store FFI), `server` (HTTP server, database, storage, garbage collection), `client` (CLI with push, watch-store, cache management), and `token` (JWT creation and verification). The architecture is modular, with clear separation between API handlers, database entities, storage backends, and authentication. While the project is still in early prototype stage with many TODOs and some fragile FFI bindings to Nix's C++ store library, it demonstrates solid engineering practices with reusable components like streaming hash readers, compression streams, and a custom serde serializer for Nix manifest format.
This repository is a comprehensive, declarative NixOS homelab configuration managed with the Clan framework. It defines the entire infrastructure for a multi-machine homelab including servers, desktops, and network devices, all version-controlled and reproducible. The system provisions self-hosted services (Caddy, Grafana, VictoriaMetrics, Vector, Blocky, Miniflux, Linkding, etc.), identity management (Authentik, Zitadel), monitoring and alerting, backup (Borgbackup), and desktop environments (KDE, i3). The architecture is modular: reusable NixOS feature modules under `modules/nixos/features/` follow a consistent pattern using `mkFeatureOptions` for enabling services with standardized options (domain, firewall, monitoring integration). Secrets are managed via SOPS with age encryption, and disk partitioning is handled by Disko templates. The repository is not a software application but an infrastructure-as-code project that demonstrates high craftsmanship in Nix module design, with clear separation of concerns, helper functions, and integration patterns. It is actively maintained but shows some technical drift due to deprecated identity providers and hardcoded IPs.
dconf2nix is a CLI tool and Haskell library that converts GNOME dconf configuration files into Nix expressions for use with Home Manager's dconf.settings option. It parses the GVariant text format using Parsec combinators, supporting a wide range of dconf value types (booleans, integers, floats, strings, byte strings, tuples, lists, variants, dictionaries, typed values, and JSON). The parser is comprehensive and handles edge cases such as hexadecimal and octal integers, scientific notation, Unicode escapes, and nested structures. The rendered output uses Home Manager's lib.hm.gvariant constructor functions to produce valid Nix code. The architecture cleanly separates parsing (DConf module), data model (DConf.Data), and Nix rendering (Nix module), with a small CLI entry point. The codebase is well-tested with 20+ test cases covering various dconf input patterns and their expected Nix output.