$ show nix-community/NUR
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.
The LLM identified 4 files worth highlighting for reuse:
Implements a Git smart HTTP ref-advertisement client that resolves the latest commit of remote repos without cloning, parsing pkt-line responses from /info/refs. It then prefetches sources via nix-prefetch-git or GitHub/GitLab archive endpoints, and distinguishes deleted repositories from infrastructure failures using HTTP status codes and DNS error semantics. This is a reusable pattern for any registry/automation tool that must continuously watch many git repositories and update lockfiles efficiently.
A pure Nix function that maps a locked revision to the correct source fetching strategy: local checkout for CI, GitHub codeload zip, GitLab API archive, or fetchgit with submodule support. It injects fetchers as arguments (fetchgit/fetchzip), making the source policy testable and reusable under restricted evaluation. Any Nix-based registry or lockfile consumer could extract this pattern for host-aware source acquisition.
Provides a clean typed model for a multi-repo manifest plus lockfile: Repo, LockedVersion, equality semantics, JSON serialization, and path traversal validation for per-repo `file` attributes. The lockfile merge logic only accepts a locked version if URL and submodule flag match, preventing cross-repo stale locks. This is a solid extractable pattern for any registry that needs a human-editable manifest paired with an automated lockfile.
Maintains a combined monorepo by copying each registered repo's source tree into a `repos/<name>` directory, committing only changed repos, removing deleted ones, and refusing to write the combined manifest if more than half of existing repos would disappear. The failure guard against catastrophic large-scale deletion is non-obvious and valuable for any automation that bulk-mirrors external repositories into a single git repository.