| 7 Aug 2021 |
 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 |
| tomberek | Okay... then i'd want some sort of warning at least if the underlying flake adds/removes their lock. (compared to the last time i updated my flake.lock). | 20:11:35 |
| balsoft | That would be fairly difficult to implement | 20:12:06 |
| balsoft | We don't keep how we got the input versions in flake.lock | 20:12:37 |
| tomberek | My thought is that it's a bigger change than one would normally expect because the semantics change a bit. Is there a warning just in the situation that there is no flake.lock? | 20:13:58 |
| balsoft | In reply to @tomberek:matrix.org
My thought is that it's a bigger change than one would normally expect because the semantics change a bit. Is there a warning just in the situation that there is no flake.lock? The PR in question doesn't change anything apart from the interactivity requirement for this particular setting. | 20:15:18 |
| tomberek | Yes, sorry. It's a slightly wider question than your PR. | 20:16:11 |
| tomberek | I think we can add an informative output any time there is no flake.lock for an input flake.
* Flake 'myflake' has no lockfile
* Updated 'myflake': ASDSAD -> ASDSADA"
| 20:22:31 |
| tomberek |
hrm... that would be super noisy with nixpkgs | 20:49:51 |
| tomberek | * I think we can add an informative output any time there is no flake.lock for an input flake.
* Flake 'myflake' is not locked
* Updated 'myflake': ASDSAD -> ASDSADA"
| 21:06:48 |
| 8 Aug 2021 |
 Las | Wasn't Nix going to support storing Git repositories natively in /nix/store? I seem to remember an issue about it on https://github.com/NixOS/nix. | 15:24:01 |
|  Kha joined the room. | 15:27:54 |
| tomberek | #1006 has discussion ^^^^ | 15:31:47 |
| Las | Thanks! | 15:32:33 |
|  infinisil removed their profile picture. | 22:48:52 |
| 9 Aug 2021 |
 manveru | i wonder if there's even a way to fix https://github.com/NixOS/nix/blob/master/src/libexpr/symbol-table.hh#L79 easily... maybe using std::unordered_set::count first to find the key without too many allocations and making life a bit easier for our GC? But of course that adds CPU overhead by doing the lookup twice... | 08:47:22 |
