search

haskell-nix / hnix-store

Haskell implementation of the Nix store
Apache License 2.0
87 stars 23 forks source link

Implement 'addToStore' #53

Closed layus closed 4 years ago

layus commented 4 years ago

This convinced me that the project is mature enough to get started with actual implementations of the store API.

Some limitations that I discovered:

  1. I needed an HashAlgorithm outside of the type system. I worked around the missing value by abusing algoName as in algoName @hashAlgo == "sha256".
  2. We cannot turn a String into a store path, because the store path has the prefix in its type. This means that we must know the prefix before reaching to the daemon, or find something to make the return value of addToStore more generic. This leads to more questions i. Does a daemon only handle one prefix ? ii. Is there a way to know the prefix used by a daemon before reaching to it ?

\cc @shlevy to get your first impressions, and possibly merge after some edits.

layus commented 4 years ago

@shlevy Updated. The code is a mess, but i implemented most of the missing features, except testing the algo in the source code. It still relies on algoName for that.

layus commented 4 years ago

@shlevy Why not merge hnix-store in the hnix repo. Further development requires changes in both hnix and hnix store, often closely related.

My work is stalled now for everything turns out to be incredibly tangled, especially while trying to make the monads in hnix-store and hnix to work together.

My wip is in my dev branch https://github.com/layus/hnix/commit/e4713cc1266571886714ad6ca7df2ed2bcdf2747, especially the snippet https://github.com/layus/hnix/blob/dev/src/Nix/Effects.hs#L244-L297 where we see the complexity of integrating both. Ideally, we would not have to call Store.runStore inside the hnix monad store, and we should be able to keep the daemon socket alive while continuing the nix evaluation.

The remaining of the wip in this branch, but it is now completely broken permalink

If I could get but only one daemon call working correctly, the rest would be much easier, being just an extension that mimics the first call. Would you try to give a shot at a complete implementation of addTextToStore for example ?

Ericson2314 commented 4 years ago

I agree with @layus that we should put things in the same repo, especially while stuff is in flux. (Of course, no packages should be combined; people should load multiple packages in one GHCi. stack can do that, and as it so happens we are finishing up https://github.com/obsidiansystems/obelisk/pull/489 to be able to do it too.)

sorki commented 4 years ago

Nice!

While I was trying to rebase my PR #35 I've got stopped by tests (once again), while I figured out something like runStore :: FilePath -> FilePath -> MonadStore ("lal" :: StoreDir) a -> IO (Either String a, [Logger]) I don't think that type level StoreDir is a correct solution as it enforces to knowing store paths ahead. Tests for example use ad-hoc temp directory not to interfere with system store.

Maybe I'm just missing something and there's a way to do it with TypeLits as well.

The other problems I found is with store path en/decoding IIRC but I need to look more closely again.

layus commented 4 years ago

I think all the features here have been added in other PRs in the meantime. Closing