A fast rust tool to check availability of your entire system in caches. It so to speak "checks the weather" before going to update. Heavily inspired by guix weather.
Find a file
Christina Sørensen 92b96dbc47
Some checks failed
Conventional Commits / Conventional Commits (pull_request) Has been cancelled
docs: more padding
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
2024-09-05 09:48:27 +02:00
.config feat: flake + lix 2024-09-05 07:32:31 +02:00
.github feat: flake + lix 2024-09-05 07:32:31 +02:00
crates fix: use native async recursion 2024-09-05 08:31:33 +02:00
LICENSES docs: readme headers, code of conduct 2024-09-05 08:50:47 +02:00
.envrc feat: flake + lix 2024-09-05 07:32:31 +02:00
.gitignore feat: flake + lix 2024-09-05 07:32:31 +02:00
Cargo.lock fix: use native async recursion 2024-09-05 08:31:33 +02:00
Cargo.toml feat: flake + lix 2024-09-05 07:32:31 +02:00
CODE_OF_CONDUCT.md docs: readme headers, code of conduct 2024-09-05 08:50:47 +02:00
deny.toml feat: flake + lix 2024-09-05 07:32:31 +02:00
flake.lock feat: flake + lix 2024-09-05 07:32:31 +02:00
flake.nix feat: flake + lix 2024-09-05 07:32:31 +02:00
justfile feat: flake + lix 2024-09-05 07:32:31 +02:00
LICENSE.txt feat: flake + lix 2024-09-05 07:32:31 +02:00
README.md docs: more padding 2024-09-05 09:48:27 +02:00
REUSE.toml feat: flake + lix 2024-09-05 07:32:31 +02:00

Weather - Check Cache Availablility of NixOS Configurations

A fast rust tool to check availability of your entire system in caches. It so to speak "checks the weather" before going to update. Heavily inspired by guix weather.

Built with Nix Contributor Covenant REUSE status License: EUPL-1.2

Usage

Note

Currently, nix-weather only has first-class support for flakes.

General usage would be like this:

nix-weather --name myhost --config ~/git/my-nixos-config

Here, we specify the name of the host, as specified at the flake output nixosConfiguration, and a path to the NixOS configuration flake.

How It Works

The basic idea is that we construct a set of all requisites to build the top-level of a NixOS configuration, and then query Nix cache(s) for the narinfo. By doing this in a high concurrency, parallel task runner (i.e. tokio async runtime), and only querying the headers for status codes, we can reach impressive speeds, typically around 45~ network time.

One of the biggest limiting factors regarding speed is building the config.system.toplevel, and finding the necessary requisites with nix-store. Caching the requisites is a future goal, so that we only have to build the toplevel, and then match against its derivation in cache, which should cut down the nix part of the runtime by ~80%.