Use harmonia-store-core to save on a lot of code

[Ericson2314]

We can get rid of nix-libstore this way.

The old nix-libstore and harmonia-store-core store path types differently, so this required a fair bit of plumbing of the store path.

As part of this, fix NixOS test failures. Putting packages in environment.systemPackages isn't correct, it should be done with nix.package. This happened to work with older nix, but doesn't anymore.

[jaen]

@Ericson2314 possibly dumb question — why that library in particular?

To elaborate on why I'm asking — there's also the nix-tool crate that does shelling out to nix to create the derivations, which probably introduces a lot of overhead. Since harmonia-store-core looks like a pure data layer, it won't help with that problem.

I vaguely remember NixOS/nix#13768, but it didn't seem to have progressed since, so not sure how much of an option it is/will be. But I've noticed that NixOps4's nix-bindings-rust has this, which looks like it could replace shelling out: https://github.com/nixops4/nix-bindings-rust/blob/main/nix-bindings-store/src/store.rs#L264-L319.

In that case, maybe it would make more sense to extend nix-bindings-rust with the data layer instead? I suppose another option would be to extend harmonia-store-remote to replicate what the commands do, but as far as I understand the problem would be the this could end up drifting from Nix's implementation, right?

What do you think would make most sense here?

[Ericson2314]

My general plan is to use harmonia-store-core to deduplicate every Nix ecosystem project in Rust I can get contribute to :). For that purpose, I do want a "pure data layer".

Re nix-bindings-rust see also nixops4/nix-bindings-rust#22 So yes that project would use harmonia-store-core.

The varlink stuff is not dead, it just was the holidays, and I had other CA things to work on first. (CA needs to be on a correct foundations before dyn derivations is ready for production.) I very much intend to get back to it, so yes I hope that there will be no need for nix-ninja to actually link upstream C++ Nix.

[jaen]

Oh, that sounds neat! And it's always nice to reduce the need for interacting with C++ - I've tried to figure out why it takes almost a second for my simple static website to rebuild on a text file change and trying to modify lockFlake to not do anything if flaek.nix didn't change was very painful xD

I'm not sure how much spare time I can find (at least until I hopefully get that NGI grant, so I can focus solely on this), but if there's a list of low-hanging fruits that help move this forward, I can try taking stabs at them opportunistically.

[artemist]

I believe that I have fixed tests, but I need to run them.

[artemist]

I continue to be extremely confused about the test failure. I have not been able to reproduce it locally, even when running the github action locally with act and using an old nix version.

This could be a consequence of a strange kernel config option on the runner.

[artemist]

We're adding code to skip the test in NixOS/nix#15444

[Ericson2314]

@artemist You should reopen this so I can approve it, and then we can merge.

[artemist]

I don't think I can reopen this, so I'll make a new PR