Content addressing and adding to store cleanup#9325
Conversation
|
|
||
| namespace nix { | ||
|
|
||
| StorePath InputAccessor::fetchToStore( |
There was a problem hiding this comment.
Just to note but some of this code is here to minimize the diff with lazy-trees. So if we start changing this, it will increases the lazy-trees diff again.
There was a problem hiding this comment.
@edolstra happy to fix that merge conflict :)
There was a problem hiding this comment.
Right now there is a conflict in lazy trees from #8848 that is very domain-specific on both side. I can't help with that so much, but I am happy to do all the other conflicts!
There was a problem hiding this comment.
fetchToStore stays non-virtual on lazy-trees so I think there is no issue here. This PR makes Store able to consume SourceAccessors directly so we just use that. Anything in an InputAcessor beyond the underlying SourceAccessor Store::addToStore won't care about anyways.
There was a problem hiding this comment.
For the fingerprinting, Sure that method could go back, but we could also flip around the logic so the SourceAccesor itself has a maybeLstat-like method to try to cheaply content-address file system object, and the InputAccesor implementations do the getCache() to look this up.
There was a problem hiding this comment.
On lazy-trees, InputAccessor::fetchToStore() implements a SQLite cache for SourcePath -> StorePath mappings that I want to backport to master. It optimizes stuff like src = <some big tree>. That's why it's important not to get rid of fetchToStore().
There was a problem hiding this comment.
It is now put back (not sure why this thread isn't marked outdated).
There was a problem hiding this comment.
Not on a red or green line, is probably why.
a1f39f5 to
2e3711a
Compare
|
Fixed the bug! |
23b70f2 to
395e3c3
Compare
roberth
left a comment
There was a problem hiding this comment.
Just one suggestion.
Great stuff: less code, more consistent use of fewer interfaces, progress towards in-memory store.
Ok to merge after the suggestion and resolving the work priority inversion. It seems that you can't help @edolstra with lazy-trees until the existing conflict is resolved.
54d85ce to
26b254b
Compare
|
@amjoseph-nixpkgs BTW this addresses some duplication you brought up a while back :) |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
26b254b to
fdc03a1
Compare
fdc03a1 to
d792a27
Compare
|
Just rebased this fixing conflicts. it would be very good to get it reviewed @edolstra so I can continue with the rest of the git hashing stuff! |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
d792a27 to
3bd924a
Compare
…tore` Co-authored-by: Robert Hensing <[email protected]>
`addTextToStore` and `computeStorePathFromDump` are now redundant. Co-authored-by: Robert Hensing <[email protected]>
3bd924a to
ed26b18
Compare
Motivation
Organize content addressing
We now better distinguish ways to:
The former has a new
underlyingmethod to give the method it uses for the latter.Use
SourceAccessorwithStore::addToStoreThis helps promote
SourceAccessor--- eventually (I think) we want just about all file system access to go directly through it and not use native operations directly. This will help us with in-memory story (good for unit tests!) and dovetails with #9278.Remove now-redundant text-hashing store methods
addTextToStoreandcomputeStorePathFromDumpare now redundant because the other methods are upgraded to take aContentAddressMethodnotFileIngestionMethod--- we have a single suite of methods that works with all types store object content adressing, and we don't need any additional methods for the Text case.Context
I was reminded how much duplicated code we had working on #8918. This is a long standing issue and it's high time we clean it up. Cleaning it up first will also make it easier to review git hashing support to libstore.
Priorities
Add 👍 to pull requests you find important.