Move this library to the hnix-store repo?

[Ericson2314]

Recently @sorki has been really cranking on hnix-store (:tada:).

That library currently depends on this, but I think there are some changes that would probably be good to make this presenting to support BasicDerivation (no inputDrvs) and exotic content addressed and dynamic-derivation-dependency-having derivations.

I am not quite sure what we want yet, I sort think it will take a few rounds of revision, and that revision would be less frictionful if it took place in the same repo. Of course hnix-store could temporarily vender this, and then un-vendor it once it settled on something with a big PR, but there is always the risk that that process doesn't finish, and we're left with a fork. Therfore I think proactively combinging repos is a decent idea.

(Of course, if we did this, you, @Gabriella439, should have commit bit on the hnix-store repo!)

[Gabriella439]

Yes, I am very okay with moving this underneath another organization and/or repo. Whenever you're ready to make the transition just let me know and I can do whatever is necessary on my end

[Ericson2314]

OK great! Belatedly I am going to take this and both outstanding PRs (#24 and #26) and merge them into hnix-store and then report back here.

[Ericson2314]

haskell-nix/hnix-store#289 WIP PR.

@Gabriella439 How much do you care about the type variables? I would like to just use the hnix-store types for the hash algo and hash fields (for derivation outputs), but I am fine either hard-coding the hnix-store StorePath type, or keeping that a type variable.

I also (and I want to do this in C++ Nix too) make expose the types separately from the ATerm serialization. There is now a JSON one too, and I would like to give them equal weight. This is good for e.g. decentering the on-disk format or replacing ATerm with JSON for newer derivation types for the on-disk format, etc. (The latter part I am concretely planning on doing, though I haven't really announced this.)

[sorki]

@Gabriella439 How much do you care about the type variables? I would like to just use the hnix-store types for the hash algo and hash fields (for derivation outputs), but I am fine either hard-coding the hnix-store StorePath type, or keeping that a type variable.

These were introduced by me due to needs of hnix-store. Years ago I've had a Derivation type and a parser in one of the store PRs, then Domen pointed me to this neat library but we also needed a custom store path type instead of just Texts (in nix-diff and nix-graph the type vars are just Texts).

Currently hnix-store-core depends on nix-derivation so that would need some shuffling. Also using store types would add a bit of parsing overhead but not too much I guess.

[Ericson2314]

Ah great, if the type variables were just introduced for us, then we should indeed not need them.