Make dummy store also store path info#14023
Conversation
github-actions
bot
added
the
store
Ericson2314
force-pushed
the
dummy-store-path-info
branch
from
2055c1c to
410cdfe
Compare
xokdvium
force-pushed
the
dummy-store-path-info
branch
2 times, most recently
from
26d5af0 to
a4cb582
Compare
xokdvium
force-pushed
the
dummy-store-path-info
branch
from
a4cb582 to
5276eee
Compare
We should use proper abstractions for reading files from the store. E.g. this caused errors when trying to download github flakes into an in-memory store in #14023.
|
🎉 All dependencies have been resolved ! |
This allows aliasing, like hard links.
xokdvium
force-pushed
the
dummy-store-path-info
branch
from
5276eee to
a453a49
Compare
github-actions
bot
added
the
with-tests
xokdvium
left a comment
xokdvium
left a comment
There was a problem hiding this comment.
Needs a bit more work to make thread-safe. Not sure if that is a a very important consideration for this first pass on this.
| /** | ||
| * This view conceptually just borrows the file systems objects of | ||
| * each store object from `contents`, and combines them together | ||
| * into one store-wide source accessor. | ||
| * | ||
| * This is needed just in order to implement `Store::getFSAccessor`. | ||
| */ | ||
| ref<MemorySourceAccessor> wholeStoreView = make_ref<MemorySourceAccessor>(); |
There was a problem hiding this comment.
This would be a lot simpler if we didn't have a store-wide getFSAccessor requirement.
Either we could keep it:
Also it seems that this is a general problem, and we could have a store mix-in that implements getFSAccessor by means of an abstract method that gets an accessor for an individual store path.
Then all synchronization would be limited to that particular method.
Or we could drop it in favor of per-store path accessors.
Then non-listable stores also become more "valid" Store implementations.
There was a problem hiding this comment.
What we also could do is have a "subdirectory" view of mounted accessors. That would help with thread safety as well.
There was a problem hiding this comment.
I like the point about non-listable stores.
The store-wide accessor could go in the same interface (in the store hierarchy) as the stuff for listing stores, like #8213
Non-listable stores can also contain different objects for different store dirs too. E.g. binary cache can be heterogeneous in store dir.
Ericson2314
left a comment
Ericson2314
left a comment
There was a problem hiding this comment.
I approve the follow up work!
3 participants
Motivation
Filling in the missing methods.
Context
See discussion in #10915. We might hereafter split
dummy://andmemory://.Depends on #14035.
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.