-
Notifications
You must be signed in to change notification settings - Fork 363
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
Save install receipt #195
Save install receipt #195
Conversation
/assign @ahmetb |
Codecov Report
@@ Coverage Diff @@
## master #195 +/- ##
=========================================
- Coverage 53.82% 53.6% -0.22%
=========================================
Files 16 16
Lines 732 735 +3
=========================================
Hits 394 394
- Misses 286 289 +3
Partials 52 52
Continue to review full report at Codecov.
|
This is a massive PR. |
But I’m glad we’ll do this before implementing multi-indexes which would definitely require this change. |
Take your time. As said elsewhere, don't hesitate to request parts being split out if you think it doesn't fit here. |
7e42a3b
to
bb0f363
Compare
bb0f363
to
42d601c
Compare
Adding corneliusweig to owners. He has been consistently helping both with krew and krew-index repositories in terms of: - developing plugins himself - taking a stab at krew machinery with large scale code refactors - adding integration test suite to the project - adding more validation and test cases - increasing developer documentation Some of his notable work: - kubernetes-sigs#195 - kubernetes-sigs#183 - kubernetes-sigs#191 - kubernetes-sigs#201 - kubernetes-sigs#202 - kubernetes-sigs#203 - kubernetes-sigs#208 He is familiar with the codebase enough to officially review and approve code. Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
Adding corneliusweig to owners. He has been consistently helping both with krew and krew-index repositories in terms of: - developing plugins himself - taking a stab at krew machinery with large scale code refactors - adding integration test suite to the project - adding more validation and test cases - increasing developer documentation Some of his notable work: - #195 - #183 - #191 - #201 - #202 - #203 - #208 He is familiar with the codebase enough to officially review and approve code. Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
This is still on my list, I'll get to reviewing hopefully soon. |
42d601c
to
89486b3
Compare
Before reading the code, I'd like to discuss some points (and this is precisely why we should design it before coding it):
Why do we need a new kind? Can't we just copy the manifest over? (This simplifies a lot.) I don't think there's any point of storing these dates.
I don't know if users can understand this easily. This is a bit "magic" behavior, and will get more complicated when we support multiple indexes and there's name collisions. We should probably look at what other package managers do to show "more info" about a package, and does the behavior change when the package is installed.
I think mostly because there aren't a lot of good reasons to use pointers.
So it doesn't add anything, consider undoing this.
I think new test dependencies are ok, our tests have been pretty lean so far, but we can change that. |
First of all, thanks for your feedback. I think it's absolutely necessary to do that even if there is a working first revistion.
So I'll only focus on point 1 and 4: 1The main reason why I introduced the new type was that it gives us more flexibility in the future. For example, when we have multiple indices and somebody introduces a name clash, we can record what the source index for the specific plugin was. The dates which I put into the receipt right now is just a nice-to-have but definitely not important. And there are for sure other important use-cases for saving metadata about the install process in the receipt, which we can't think of right now. 4I don't agree that this appears magic to users. It should be quite obvious that |
I'd like to hammer on this, it really does simplify, and I don't think there's much value of showing dates of installation. Most other package managers don't do this either. The TOP reason to save install receipt is the ability to uninstall plugins that don't exit/never existed in the index. I'm not entirely opposing the idea. It's just low-priority to me. We can introduce a
To me |
Yeah, let's keep it simple. If we really must add install metadata, we can add fields to the plugin manifest which should not be populated by plugin authors but only by |
89486b3
to
eb428ac
Compare
Saving receipts is less prone to failure than the whole plugin installation. When swapped, krew will have an inconsistent state in fewer occasions.
…r when plugin does not exist
055aa1c
to
6d78644
Compare
I've just tested this, it's mostly good to go. I have several questions, I'm curious when do you want to address them, as they're breaking changes:
Should we do this breaking change later? Seems like this PR does what it says ("save install receipt") as it saves the receipt on install and upgrades. |
@ahmetb Thanks for another close look at this PR. Storing the install receipt for upgrades should be part of this PR. The other points you raised are all valid. But they are pretty independent, so I would rather not include them here. As stated in the first PR comment, this requires some migration of the EDIT: I opened #232 to discuss the migration plan. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahmetb, corneliusweig The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Looks like we didn't address the code review comment at kubernetes-sigs#195 (comment). Copying the conversation from there: > This is better because: > > - actually installing a plugin (extract files, symlink binary) but then failing > to store the receipt is okay (at most you'd be leaking some files) > - claiming the plugin is installed (i.e. receipt exists) while it's not > installed is not okay. > - tens of things can go wrong in `install()`, much fewer things can go wrong > in `receipt.Store()`, so makes sense to do it last. Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* pkg/installation: reorder receipt save & install() Looks like we didn't address the code review comment at #195 (comment). Copying the conversation from there: > This is better because: > > - actually installing a plugin (extract files, symlink binary) but then failing > to store the receipt is okay (at most you'd be leaking some files) > - claiming the plugin is installed (i.e. receipt exists) while it's not > installed is not okay. > - tens of things can go wrong in `install()`, much fewer things can go wrong > in `receipt.Store()`, so makes sense to do it last. Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com> * pkg/installation: reorder receipt saving in uninstall() Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
I want to add more tests, however I would ask for some early feedback whether you like the direction this is taking.
Summary of changes
krew info
command now looks for index manifests, and receipts. If a receipt is found, the shown information is slightly augmented.google/go-cmp
was added and vendored. If you don't like this, I can also do this manually, but the test assertions won't be so pretty. Otherwise, this library should be used in a few more places.Todos
There are some loose ends that should probably be taken up in other PRs, because this one is already quite large:
Close #163