feat: add support for layered package cache #1003
Conversation
|
Hi @kelvinou01 - I also started hacking on this a bit but it looks like you are already much further progressed :) Here was my attempt: #998 |
|
@kelvinou01 is this pr ready? |
|
it seems the pr does not contains the changes of the config key. |
@gzm55 not yet, is there an urgent need for it? |
|
no urgent need. but expect this feature for multi-user environment |
|
when select a read or write cache, can we prefer the one from which we can make a hard link? |
|
@gzm55 I see how that can be useful! Do you think this feature is necessary to introduce with this PR, or can we do it in a subsequent one as i mentioned above? |
I think a subsequent pr for the feature mentioned above is ok. |
|
|
||
| /// Constructs a new [`PackageCache`] located at the specified paths. | ||
| /// Read-only layers are queried first. | ||
| /// Within read-only layers, the ordering is defined in this constructor. Ditto for writable layers. |
There was a problem hiding this comment.
I dont fully understand this comment and I also dont see how it relates to the code? To me it makes most sense to pass in the paths in the order the user wants the layers to be ordered.
I would assume you look through the layers in the order they are passed in, and only write to the first writable layer.
There was a problem hiding this comment.
Seems like I didn't make the comment clear. What I meant was, the querying order is defined by
- Primary key: read-only before write-only
- Secondary key: order it was passed into the constructor
But now that I think about it, querying all layers in the order passed into the constructor makes more sense. I changed the constructor's code and docstr to reflect this.
|
@baszalmstra is there other suggestions about this pr? |
Description
Resolves #43
Stuff to note
PackageCacheErrora#[non_exhaustive]enum, and modified some variants.Old PR for ref