-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote store #59
Remote store #59
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whaaaow ! An impressive piece of work. Just nitpicks for now, but I will definitely try it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 - I like the simpler StorePath type.
addToStore name pth recursive algoProxy pfilter repair = do | ||
|
||
-- TODO: Is this lazy enough? We need `B.putLazyByteString bs` to stream `bs` | ||
bs :: BSL.ByteString <- liftIO $ B.runPut . putNar <$> localPackNar narEffectsIO pth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to use a streaming library here (so that adding files or consuming logs incrementally uses the same mechanism)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, even NARs needs streaming library (#51).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, this is great work. Thanks !
Putting typed store paths aside is a wise move. We can still reintroduce them later on if we feel so.
makeStorePathName :: Text -> Either String StorePathName | ||
makeStorePathName n = case validStorePathName n of | ||
True -> Right $ StorePathName n | ||
False -> Left $ reasonInvalid n | ||
|
||
reasonInvalid n | n == "" = "Empty name" | ||
reasonInvalid n | (T.length n > 211) = "Path too long" | ||
reasonInvalid n | (T.head n == '.') = "Leading dot" | ||
reasonInvalid n | otherwise = "Invalid character" | ||
|
||
validStorePathName "" = False | ||
validStorePathName n = (T.length n <= 211) | ||
&& T.head n /= '.' | ||
&& T.all validChar n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make sense to merge the three functions into one. Such as to avoid duplication of all the conditions. Then validStorePathName = isRight . makeStorePathName
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I think I was going to use validStorePathName
with Arbitrary
but decided against that.
|
||
next <- go decoder | ||
return $ next | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This "async read" part of the protocol looks really weird. Any idea why it was implemented like that in the daemon ?
cc @shlevy would be amazing if you can take a look at this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I have finally finished my prim_derivationStrict implementation based on your PR. It wokrs perfectly well for writing derivations, generating store paths and fixedOutput store paths, and reading the derivations.
I did not test the building part about getting the build result and triggering builds.
However I think this PR is quite ready to merge, and should not be delayed for too long. Types seem consistent. Further fixes to the implementation can be added later on. What do you think ?
@layus Nice! Can you point me to the I also have few changes pending from yesterday to this PR but nothing that should clash with your commits it seems. |
Fixed usage of obsolete |
There is a big pain point with path filters in the sense that they are generally nix functions to be evaluated inside MonadNix, which itself relies on the store. Is there a way to cope with this circular dependency ? |
buildDerivation p drv buildMode = do | ||
runOpArgs BuildDerivation $ do | ||
putPath p | ||
putDerivation drv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This design decision bugs me in the nix protocol. At that point, the .drv is already present in the store. Why not provide a buildDerivation(/nix/store/xxx.drv)
? I guess the reason is about garbage collection and such, but still. What is the point of writing .drv's to the store then ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or rather, why do we have to upload both the path and the drv itself ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind, I found the wopBuildPaths that does exactly that. wopBuildDerivation is pretty specific for "anonymous" builds and was introduced for hydra in NixOS/nix@1511aa9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the commit link. I was a bit confused about that as well.
-- XXX: reason for this is unknown | ||
-- but without it protocol just hangs waiting for | ||
-- more data. Needs investigation | ||
putInt 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only thing I could see is that libstore has a flush() operation. But possibly it's just putEnum that is not up to the task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might be right about putEnum
since it's the only use of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't make much sense either, putEnum
is just putInt . fromEnum
so it's more like missing field. I don't care that much at this point as I'm playing with local store and daemon impl. so I'll be able to end-to-end test this without nix-daemon and the reason will probably become clear.
|
@layus I think that proper use of effects and possibly introducing a library like |
Added |
I'll do one final pass over this, add changelog for |
Disabled by default since it requires `nix-daemon` binary and Linux namespaces support. For development this can be enabled by ``` cabal configure --flag=io-testsuite ``` or by adding ``` flags: +io-testsuite ``` to `cabal.project.local` Enabled by `callCabal2nixWithOptions` in `overlay.nix` so it is tested by `nix-build` and `nix-shell` brings all test dependencies. This is fine on NixOS where `build-tool-depends: nix:nix-daemon` works and we have namespaces supported.
ChangeLogs done, added dff7527 which puts Final pass hopefully, leaving open for few more days if anyone wants to chime in. |
@sorki Where can I find out more about the context and goal of this work? Apparently this Is there any more information on what Apologies if this is not a good place for these questions! I'm just a bit curious. |
This is mostly an adaptation of previous work to changes in Few missing bits were added as well, especially
Currently the goal is to allow interacting with
I hope but the description is too vague :)
Part of https://github.com/haskell-nix/hnix-store#rationale is good overview, now when you asked you reminded me it needs an update to reflect the current state since |
Summary
TypeLits
and symbolic store path rootaddToStoreNar
now works and has a testregex-tdfa
, uses simpler solution, original regex wouldn't roundtrip and it was the only use ofregex-tdfa
The reason for dropping symbolic
StoreDir
is that knowing path at compile time seems too restrictive and prevents us working with any store root (as the test do - tests run namespaced and create and-hoc store in temporary directory not to interfere with systems nix store). Maybe there is a way to have this level of type safety on top of store implementations but making them part ofStorePath
complicates things quite a lot. If anyone see a better solution I'm open to ideas.Can also split this into multiple commits if that would be better.