| 19 Sep 2025 |
 Sergei Zimmerman (xokdvium) | In reply to @getchoo:matrix.org
i think the latter would be good to add in any case…but looking at the current workflows, it’s kinda a mess IMO
i was wondering if everyone would be ok with a major refactoring of it all? mainly just making things a proper matrix job instead of having a ton of copy-pasted individual steps and workflows? Go for it in any case. The tests jobs could use some love.
Also it would be great to run NixOS tests with sanitizers on GHA and hydra. It’s almost wired up and just needs a proper matrix set up | 07:37:05 |
 jaen | Any suggestions on that? Want to continue with the rebase this weekend, but had no time to think on how to resolve that. One odd-hand idea I didn't test is that this is being specified in the devshell:
https://github.com/NixOS/experimental-nix-installer/blob/main/Cargo.toml#L74
https://github.com/NixOS/experimental-nix-installer/blob/main/flake.nix#L168
so maybe that envvar could be reused in the test? Didn't test that yet and not quite sure what the expectation of this tests is given that this profile does not exist on any of my NixOS machines — are my machines set up incorrectly or is the upstream installer making some weird assumption? Or maybe the test should create a temporary directory with a profile and pass that? Sorry if the answer is obvious, didn't really come across that particular issue before. | 11:58:24 |
 John Ericson | fzakaria: https://github.com/NixOS/nix/pull/14023/files OK here is WIP thing | 16:14:15 |
| John Ericson | Sergei Zimmerman (xokdvium): ^ this has one of the worst C++ errors I've every seen! | 16:14:29 |
| John Ericson | I think my wrapper constructor for the std::variant class is shadowing a built-in constructor | 16:14:51 |
| John Ericson | but also the template instation trace in the diagnostic is missing | 16:15:11 |
 fzakaria | why does it need whoelStoreView | 16:15:25 |
| John Ericson | so I can't tell how things are being invoked / ultimately from what | 16:15:27 |
| John Ericson | for get getFSAccessor method | 16:15:40 |
| John Ericson | maybe that should be changed so you can only ask the store for individual object source accessors | 16:15:55 |
| John Ericson | but that is a separate refactor | 16:15:59 |
| John Ericson | and that also may not work | 16:16:03 |
| fzakaria | oh you merge it | 16:16:15 |
| fzakaria | on every call to addtoStore | 16:16:32 |
| John Ericson | yeah I am using shared pointers, but conceptually the std::map<StorePath, ....> owns the data | 16:16:39 |
| fzakaria | why is it only addToStoreFromDump and not addToStore | 16:16:45 |
| John Ericson | and the view is just splatting those together | 16:16:46 |
| fzakaria | addToStore is unsupported | 16:16:57 |
| John Ericson | simply because I didn't do the other methods yet | 16:16:58 |
| fzakaria | oh | 16:17:06 |
| fzakaria | ok | 16:17:07 |
| fzakaria | sorry | 16:17:08 |
| John Ericson | I think we need Sergei Zimmerman (xokdvium)'s help to fix the type error 😅 but after that, you are welcome to do the rest | 16:17:28 |
| fzakaria | I think i see what you mean:
ref<MemorySourceAccessor> wholeStoreView = make_ref<MemorySourceAccessor>();
That is probably a pattern (Delegating MemorySource Accessor or Composite accessor)
| 16:18:05 |
| John Ericson | I think that line is fine? | 16:18:20 |
| John Ericson | I am not sure though | 16:18:23 |
| John Ericson | will try changing it | 16:18:24 |
| fzakaria | i meant having 1 accessor but have it hide away the fact it's multiple; but maybe that doesn't matter once you do whatever subsequent refactor you meant | 16:19:00 |
| John Ericson | oh ok | 16:19:21 |
| fzakaria | i might epxlore after your work; the sqlite variant.... it's got a worm in my brain about it.
I like that sqlite can do in-memory or also persist to a file. | 16:19:50 |
