| 5 Aug 2021 |
 John Ericson | * do the store-specific options not get put in the manual yet? | 17:38:20 |
 Regnat | No, I don’t think they are. They are only available with nix describe-stores | 20:32:40 |
| 6 Aug 2021 |
|  Rev. CornWallace III (novus ordo seclorum) changed their display name from continuouswave to cw (? days since last shower). | 18:10:47 |
|  Robert Hensing (roberth) changed their display name from roberth to Robert Hensing (roberth). | 19:46:50 |
|  ash (it/its) 🏳️⚧️ changed their display name from ashkitten (it/its) 🏳️⚧️ to kity. | 21:02:52 |
| ash (it/its) 🏳️⚧️ changed their display name from kity to ash (it/its). | 21:03:40 |
| ash (it/its) 🏳️⚧️ changed their display name from ash (it/its) to ash (it/its) 🏳️⚧️. | 21:04:53 |
 fzakaria | Small fix for the issue i filed above | 22:37:17 |
| fzakaria | https://github.com/NixOS/nix/pull/5101 | 22:37:18 |
 tomberek | In reply to @theophane:hufschmitt.net
No, I don’t think they are. They are only available with nix describe-stores I’ve always found myself going through the code to find them. Wasn’t aware of this command. Thanks! | 23:00:41 |
| 7 Aug 2021 |
 balsoft | https://github.com/NixOS/nix/pull/5102 is a very simple change, but it empowers us to use nixConfig.flake-registry for automatically keeping input versions up to date. It should be safe. | 11:44:33 |
| tomberek | balsoft: this changes the concept of a registry a bit. How would this work when a flake depends on another? or "follows"? What if they depend on different flakes? | 18:31:20 |
| tomberek | * balsoft: this changes the concept of a registry a bit. How would this work when a flake depends on another? or "follows"? What if they depend on different registries? | 18:31:50 |
| balsoft | In reply to @tomberek:matrix.org
balsoft: this changes the concept of a registry a bit. How would this work when a flake depends on another? or "follows"? What if they depend on different registries? No, it doesn't change the concept of anything. Only top-level flake registry matters | 19:57:31 |
| balsoft | * Only top-level flake nixConfig gets applied | 19:57:39 |
| balsoft | * Only top-level flake nixConfig gets applied | 19:57:58 |
| tomberek | i see. This means any other input flakes would use the overridden registry? | 19:59:38 |
| balsoft | In reply to @tomberek:matrix.org
i see. This means any other input flakes would use the overridden registry? Other flakes won't use the registry at all, unless they are missing a lockfile. | 20:01:47 |
| balsoft | In which case yes, they would be using that registry when you update the top-level flake. | 20:02:04 |
| balsoft | Besides, this PR doesn't actually change any of this behavior, that was done in https://github.com/NixOS/nix/pull/4969 | 20:03:04 |
| balsoft | This just whitelists nixConfig.flake-registry so that it can be used in non-interactive settings, e.g. an automatic update bot (https://github.com/serokell/update-daemon) | 20:03:41 |
| balsoft | Currently we hack this by adding .local/share/nix/trusted-settings.json with the relevant value, but since flake-registry is safe to set we can avoid that. | 20:04:36 |
| tomberek | okay, then the PR seems fine, but the underlying semantics are what I'm trying to understand. At first glance it seems an input adding or removing a .lock might be unexpected. Can you share about what the right mental model is for this? | 20:06:23 |
| balsoft | It is safe to set because it should be exactly the same as just setting inputs in the flake. | 20:06:20 |
| balsoft | In reply to @tomberek:matrix.org
okay, then the PR seems fine, but the underlying semantics are what I'm trying to understand. At first glance it seems an input adding or removing a .lock might be unexpected. Can you share about what the right mental model is for this? I'm not sure I understand the question. | 20:06:49 |
| balsoft | The flake registry is not the source of truth for most flakes, flake.lock is. | 20:07:13 |
| balsoft | And even in flakes that don't have flake.lock, the registry only matters for indirect inputs, which should be avoided in such situations. | 20:07:39 |
| balsoft | The slightly unexpected thing is that if you set nixConfig.flake-registry, don't add any explicit inputs, don't commit the lockfile, and then use your flake in another flake you will get different input versions (or it wouldn't work at all) | 20:08:25 |
| tomberek | a project that does not have a flake.lock inherits the registry resolution from the very top. Otherwise it is not impacted. (i'm just thinking through it...) | 20:08:51 |
| balsoft | Yes, exactly. | 20:09:02 |
