I built a Nix binary cache backed by Git (82% storage reduction)

[ttamttam1]

@EphraimSiegfried

Yes I also thought about using symbolic references to mimic user profiles. I was wondering whether we could do something similar to a Nix store if we would merge all commits that a user wanted. But this would not work because of merge conflicts. Instead we would have to construct a super tree pointing to all packages (represented as trees) that a user wants.

The usecase I was thinking of was akin to Cachix deploy, where clients could query their symbolic reference and get back a system closure. You can of course do this with a nornal nix store and a db or symbolic refernces in a var directory, but this seems very clean.

@EphraimSiegfried

That’s a tough problem, I admittedly have not considered. I didn’t know that there could be different content outputs for the same input addressed package. If that is the case we could probably only index Nix packages in the Gachix database using Nix content-addessed hashes. Or do you have a suggestion for a working solution to this problem?

It really shouldn’t for the vast majority of input addressed store objects.[Edit: I guess it’s more common than I thought] Per RFC0062:

Unresolved questions

Caching of non-deterministic paths

A big question is about mixing remote-caching and non-determinism. As Eelco’s phd thesis states, caching CA paths raises a number of questions when building that path is non-deterministic (because two different stores can have two different outputs for the same path, which might lead to
some dependencies being duplicated in the closure of a dependency).

The current implementation has a naive approach that just forbids fetching a path if the local system has a different realisation for the same drv output. This approach is simple and correct, but it’s possible that it might not be good-enough in practice as it can result in a totally useless binary cache in some pathological cases.

There exist some better solutions to this problem (including one presented in Eelco’s thesis), but there are much more complex, so it’s probably not worth investing in them until we’re sure that they are needed.

So I largely don’t think it is an issue but it is also true that the same derivation can produce the different outputs in some particularly difficult cases, making it non-deterministic.

The nix manual as far as I’ve skimmed, doesn’t explicitly state that input-addressed outputs aren’t necessarily reproducible, but it doesn’t say they are either. It does say that fixed output content addressed outputs are reproducicible, which makes sense because that’s what makes them fixed output.

The draft for RFC0017 suggests that outputs from derivations are not fixed, and that it’s okay to have one output produce multiple content addressed store objects:

A note on reproducibility

There is no need for a given $out to always generate the same $cas. It allows better resource use, but doesn’t change anything about this RFC. There is no obligation that a single $out only stores a single $cas entry.

This to me suggests that input addressed store objects are often reproducible but not necessarily always reproducible.

As for solutions, I think you’d have to see how much this happens in practice and if any issues occur when it does. It might be a non-issue for 99% of packages. I’m sure someone on here has a better idea for properly managing it.