Or at least I think that’s what’s going on …
So I’ve been trying to learn Nix and I have been trudging along with this PR that adds the extrafiles plugin to the
beets package. Initially I disabled the Python unit tests for the plugin just to try to get the thing running at all. Eventually I got it into a working state. I added my branch of my nixpkgs fork as an overlay to my
Then I enabled and configured beets via home-manager, which is installed as a NixOS module. After a
nixos-rebuild switch beets was installed, the new plugin was enabled, and I imported an album and it successfully used the new plugin to move related files along with the music files. Clearly the PR works in general.
So now I know it works, but I wanted to see how the unit tests would fare. I commented out the overlay and the beets config in home-manager, made sure to delete the
result folder in nixpkgs, again ran
nixos-rebuild switch, ran
nix-collect-garbage -d, rebooted, probably ran garbage collection a few more times, thinking this would purge beets entirely from my system. And indeed it was not on the path any longer. But when I ran
nix-build -A beets in the nixpkgs folder it completed instantly with only a few lines of output and didn’t run the numerous unit tests again. I found out about the
--check option, so ran
nix-build -A beets --check. It ran all the unit tests again, yay! Except by default the new plugin is disabled so that only checked that the base
beets package tests work, not any of the plugins.
I still can’t figure out how to customize the input arguments with
nix-build, so I thought maybe locally in nixpkgs I can just flip
enableExtraFiles ? false to
enableExtraFiles ? true. Nope, now I get
error: some outputs of '/nix/store/nd4l6wjdpkagv9v9gg5adx88253cxi54-beets-1.4.9.drv' are not valid, so checking is not possible.
At this point I go back to my original question, why was beets not “installed” but even after garbage collection running
nix-build -A beets was basically instant? It makes it seem like it’s still around on my system/cached. And now I am just wanting to completely nuke any references to
beets for now just to rule out any leftover weirdness. OK let’s look in the store:
❯ sudo find /nix/store -name '*beets*' /nix/store/fpjicwvy03g6ypri5g22w10a8bpzhxyy-home-manager/home-manager/modules/programs/beets.nix /nix/store/wpvhvkrvll46snnpfrxbp5265jnsw589-nixos-20.09pre236721.840c782d507/nixos/pkgs/tools/audio/beets
There you are! I try deleting it from the store, it tells me it’s still referred to. OK what’s the referrer?
❯ nix-store --query --referrers /nix/store/wpvhvkrvll46snnpfrxbp5265jnsw589-nixos-20.09pre236721.840c782d507/nixos/pkgs/tools/audio/beets /nix/store/1l208k7d2n3cpca081h6j9z4habwnccf-env-manifest.nix /nix/store/3wkljzkax8yk3hwsamd7a7kwvwnkvfka-user-environment
I check out the first path and it’s home-manager apparently. So is it normal for
beets to still be in the store after removing from
configuration.nix and running garbage collection? Or does that maybe have nothing to do with my problem? If that’s the case, how do I try running the unit tests for the new beets plugin locally from the nixpkgs folder (meaning my locally cloned fork of nixpkgs repo)?