-
Notifications
You must be signed in to change notification settings - Fork 16
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
refactor(commands): decouple logic from option structs for check, prune, repair, key, and restore #317
Conversation
I agree to this refactor. Most changes are actually non-breaking as they are all offered to the users via the Besides this, we should either postpone the topic or (preferably) merge it fast. Leaving it for some time just increases the cost of this... ;-) |
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
2c73041
to
fc3d65e
Compare
It's true, all the changes are non-breaking now. I added the I made single commits for each command being decoupled and force pushed, so it's easier to review. |
Based on #317 Signed-off-by: simonsan <14062932+simonsan@users.noreply.github.com>
## 🤖 New release * `rustic_core`: 0.5.1 -> 0.5.2 (✓ API compatible changes) <details><summary><i><b>Changelog</b></i></summary><p> ## `rustic_core` <blockquote> ## [0.5.2](rustic_core-v0.5.1...rustic_core-v0.5.2) - 2024-10-09 ### Fixed - *(errors)* use correct error variant for data encryption ([#323](#323)) - *(errors)* handle out of bounds access in PathList display ([#313](#313)) - *(errors)* better error message for hot/cold repo in check ([#297](#297)) ### Other - *(commands)* decouple logic from option structs for check, prune, repair, key, and restore ([#317](#317)) - *(errors)* improve message and add logging when sending tree from backend panics ([#314](#314)) </blockquote> </p></details> --- This PR was generated with [release-plz](https://github.com/MarcoIeni/release-plz/). Co-authored-by: rustic-release-plz[bot] <182542030+rustic-release-plz[bot]@users.noreply.github.com>
I saw in #224 that
CheckOptions::run()
has been moved to typeCheckResultsCollector
. In other commands we actually have functions, not associated to any type, that take their options as parameters. I applied this here to check, prune, repair, key, and restore as well. Because I think it reduces coupling and increases testability.The idea behind having these standalone functions is, that check, prune, repair, key, and restore are not run on their options (as a method of e.g.
CheckOptions
), but rather take parameters, where one is the e.g.CheckOption
itself.In principle: methods that implement commands don't operate on their own options and have side effects on other types - options are passed into functions as parameters.
Furthermore, a
check()
onCheckOptions
sounds if it validates these options itself, rather than being run on an external type. I think from that POV it also makes sense to have such freestanding functions as entry point to our commands inrustic_core
.