This is the initial released of nix-weather, a cli-tool written in Rust, that checks how many of your NixOS system’s build dependencies are in a binary cache.
$ nix-weather -n myhost -c /etc/config/
Found Nix Requisites in 8 seconds
Checked 2789 packages in 1 seconds
Found 2676/2789 (95.95%) in cache
Specifically, this solves a problem we’ve had at DBC Digital where we come back to the office on Mondays, start deploying an update, and find that all of the CUDA related packages we need haven’t hit cache yet, making deployments take much longer than if we’d just waited a bit.
So to speak, it checks if the “weather on the cache” is bad today.
Feel free to try it out from the GitHub mirror (it’s likely faster than my forgejo instance, and I’d appreciate saving the bandwidth). Also, be aware that this is still a very early prototype, and is likely gonna see many breaking changes in the future.
Someone once told me that “Guix developers are not very good at achieving interoperability between different platforms, which is why they have not had an unstable channel like nixos, and have come up with something as crappy as guix-weather” and now we have nix-weather
given the repos seem not open to filing threads (fem.gg closed to signup, the github repo not having an issue list): it would be nice if this were compatible with lix as well , currently that seems not to like the used pipe-operator experimental feature.
find that all of the CUDA related packages we need haven’t hit cache yet
Does this imply that your input (flake or otherwise) is getting updated before the cached artifacts are available?
Is this due to nixpkgs’s branches moving before the artifacts are all uploaded to the cache? Or is this more about some other repos you use?
Just wondering, since in the past I’ve had doubts about whether the branch update is perfectly synchronized after all hydra artifacts for the channel were pushed to the cache. In my opinion, if that’s not synchronized, maybe we should try to fix that?
Thanks, I’ll open an issue (haven’t triaged yet). I haven’t had time to setup some actual way to collaborate on the project yet via the forge (so far I’ve just received emails and email patches, I may document that).
Yes, the way it works is we first bump the inputs, and then a CI step starts building and pushing to the cache.
I’ve had similar suspicions at one point when waiting for Linux 6.11 to get merged, and there was a brief amount of time where it didn’t seem to get the right version (so not specifically a cache miss), but it did seem to have something to do with some cache ttl elsewhere. I think it could be interesting to explore thou.
hey there, i think you mentioned someone had made an application similar to nix-weather since. i was wondering, which one was that?
it might be interesting to mention related works like that in the readme as well.
, currently that seems not to like the used 
question: