How to check if a binary cache contains substitutes? [multi-user edition]

[copumpkin]

I've been using the wonderful nix-build --dry-run invocation to figure out if a binary cache has substitutes for expressions of my choice, but now that macOS has a multi-user installer I'm now running into issues because my binary caches aren't necessarily going to be in nix.conf for the daemon.

At the same time, because this is --dry-run, it doesn't feel like the whole trusted-binary-caches logic should really apply, but it does, so I'm wondering what other options I have.

I've been experimenting with 1.12 and the flexible store URIs to try to work around it, but haven't yet found the right way to make that work. And with 1.11 I'm not sure what other options I have.

@edolstra @shlevy any suggestions? It might be nice to make this first-class functionality in the new UI.

[vcunat]

All the nix.conf options are overridable on command-line via --option, aren't they?

[copumpkin]

Apparently not if NIX_REMOTE=daemon, since (without --dry-run) it would be a security vulnerability?

[copumpkin]

I guess just setting NIX_REMOTE= is sufficient.

[vcunat]

And you want to avoid sudo? EDIT: ah, I missed the last comment.

[copumpkin]

Yeah. Doesn't seem like it should be necessary to be superuser to test if a remote binary cache contains some hashes 😄 it's also a PITA to be superuser in one of my test suites where I use this.

[vcunat]

Well, yes, but why does one want to test existence of packages that (s)he won't be able to substitute?

[copumpkin]

I'm testing some code whose job is to manage a binary cache 😄 so I'm trying to check on what's in it and don't particularly care about using that stuff.

[copumpkin]

There's also some annoyance with even nix-build --dry-run considering the state of the local store when showing me what to download, so it's not so much a "what's in the binary cache" as much as a "what's in the binary cache that I don't already have", which in some cases can be quite annoying.

[copumpkin]

I've mostly worked around the issue above by using a custom throwaway store in 1.12.

One thing that's sort of annoying about this --dry-run approach vs. a more first-class "does binary cache contain this stuff" tool is that if the binary cache doesn't contain X, we might well end up downloading more than before from it because now we need to download build-time deps of X in order to build X locally. It'd be nice to be able to determine that stuff in isolation.

[vcunat]

I imagine nix-env -qas -A attribute might do that, but it's certainly not a good API for that.

[teto]

I have been using nix-build -A mypkg --option substituters 's3://REDACTED?region=eu-central-1&profile=nix-daemon' --option narinfo-cache-negative-ttl 0 --option narinfo-cache-positive-ttl 0. Is that correct ? --dry-run returns no output so not effective and increasing verbosity can be too hard to parse (I mean, I would rather read a yes/no answer) .

[stale[bot]]

I marked this as stale due to inactivity. → More info

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/check-if-package-is-available-in-cache/13831/1

[stale[bot]]

I marked this as stale due to inactivity. → More info

[svallory]

I cannot believe how hard it is to get some simple info from Nix. Maaan... seems like nobody cares about cache or pinning specific versions (by the semver)