ruby

went from "fuck, root filesystem is corrupted and i can't import the zpool without the zfs module panicking" to "desktop is back to exactly how i left it this morning" within ~4 hours. such is the power of nixos+zfs snapshotting/sending

i hate bisecting nixpkgs i hate bisecting nixpkgs i hate bisecting nixpkgs i hate bisecting nixpkgs i ha

i got hit by this and someone has to figure it out because that one is nasty. like i can't use my yubikey for gpg because of it and i do that all the time

as a nixos daily driver of at least 3 years, this is 100% accurate

A handy trick i learned from @wiggles is that you can set the tarball-ttl nix.conf option if you don't want the nixpkgs flake to keep downloading nixpkgs every hour

For example, I'm the sort of person that likes to temporarily obtain various packages from the latest Nixpkgs like this:

$ nix shell nixpkgs#jq

… but the problem with that is that if it's been more than an hour since the last time I did something like that then it will redownload Nixpkgs, which is pretty slow (takes a minute or two).

So, like, I like to be on the bleeding edge but I don't need to be that much on the bleeding edge. I'd be fine if my local Nix installation were to only update the nixpkgs flake reference once a week instead of once an hour.

Enter the tarball-ttl option:

tarball-ttl

The number of seconds a downloaded tarball is considered fresh. If the cached tarball is stale, Nix will check whether it is still up to date using the ETag header. Nix will download a new version if the ETag header is unsupported, or the cached ETag doesn't match.

Setting the TTL to 0 forces Nix to always check if the tarball is up to date.

Nix caches tarballs in $XDG_CACHE_HOME/nix/tarballs.

Files fetched via NIX_PATH, fetchGit, fetchMercurial, fetchTarball, and fetchurl respect this TTL.

Default: 3600

It's not obvious from the documentation (but I created a PR to fix that), but this option also governs how quickly a flake URI like nixpkgs#… is refreshed by re-downloading the repository source archive. So if I set it to something like:

tarball-ttl = 604800

… then the nixpkgs reference will only get locked once a week instead of once an hour.

i haven't really run into the thing being described here, and i think it's because of this little snippet in my config:

nix.registry.nixpkgs = {
  from = {
    id = "nixpkgs";
    type = "indirect";
  };
  flake = inputs.nixpkgs;
};

what's happening here is the path to nixpkgs in the flake registry is being set to the same clone of nixpkgs that gets passed into the flake inputs. this way, nixpkgs refers to the same nixpkgs version that my system runs, and i don't need to keep redownloading nixpkgs all the time. i kinda prefer this since it ensures that the same nixpkgs set is used both in the command-line tools and in building my system, so i don't get surprised when i quickly check some command in nix shell, then add it to my system config, only to find that my flake's checkout hasn't picked up a derivation update yet.

inputs is coming in as an argument to the nixos module, which i get by passing it in specialArgs in the nixosSystem call. you could do this for any flake you have as an input, which could be useful for any other flakes you might use regularly.

BONUS POINTS: you can also do this for NIX_PATH entries:

nix.nixPath = [ "nixpkgs=${inputs.nixpkgs}" ];

now you have a cached-per-generation, consistently versioned nixpkgs across both flake-based and channel-based commands! great if you're like me and just can't shake nix-shell -p <whatever> from your muscle memory