-
Notifications
You must be signed in to change notification settings - Fork 204
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
Replace verdi database
commands with verdi storage
#5228
Replace verdi database
commands with verdi storage
#5228
Conversation
031d27b
to
9c0c6a2
Compare
Codecov Report
@@ Coverage Diff @@
## develop #5228 +/- ##
===========================================
+ Coverage 81.20% 81.23% +0.04%
===========================================
Files 532 533 +1
Lines 37371 37345 -26
===========================================
- Hits 30344 30335 -9
+ Misses 7027 7010 -17
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
9c0c6a2
to
368d441
Compare
The following specific commands were moved: - integrity: the checks that were performed here are no longer relevant. There will be a new verdi storage integrity that will perform more general checks (once the features of the repository are implemented). - migrate: moved to `verdi storage migrate`. - summary: information now available through `verdi storage info`. - version: information now available through `verdi status`. The respective tests were adapted as well.
368d441
to
1e27f3b
Compare
I think this is ready for review. I moved the stuff around and added a couple of tests to cover some parts of the migration that was not previously being tested (now the only part not being tested is the re-prompting but I'm not sure how to trigger that with the (@chrisjsewell I put @sphuber as the reviewer because I didn't want to bother you during your holidays, but obviously feel free to take a look too) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ramirezfranciscof . Looks good, just some comments.
echo.echo(backend_manager.get_schema_version_database()) | ||
.. deprecated:: v2.1.0 | ||
""" | ||
echo.echo_warning( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a dedicated decorator for this. Probably best to use that. Its in aiida.cmdline.utils.decorators
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, will do. A couple of questions though:
- I see it takes care of the warning, but should I still leave the
.. deprecated:: v2.1.0
in the docstring? - Do I just decorate the end commands? Just the group? Both the group and the end commands?
- I didn't find anything on the docs or the wiki for deprecations of the CLI, should I maybe add this info to the wiki?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Yes, I think leaving the explicit deprecated in the docstring is ok. But I think it should mention the version when it was deprecated, not when it is going to be removed.
- definitely the leaf commands as the group is not really called (just for the help) but if it works, why not also add it there.
- Feel free to add it to the wiki. Since this is a developer's aspect, it should go there and not the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I see. But then how do we keep easy track of when we agreed to remove something? I included this info in the deprecation warning now but on second thought I am not sure this is something we want to show to the user necessarily... 🤔
- Nah, in the end it did nothing for the groups, not even showed up if I tried using the help. But I think if this is a limitation of the decorator we could maybe extend it to also work on groups no? If it is even possible. For the future anyways.
- Check out if you think it is clear: wiki section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine to mention to the user when we are planning on removing it. Why wouldn't we? This shouldn't be a secret should it and it affects them.
Co-authored-by: Sebastiaan Huber <[email protected]>
9e3017c
to
55c8b7e
Compare
I think I addressed all the comments now (even changing the ones about which I still have some reservations =P). Ready for a second (last? 😬) pass whenever you can @sphuber. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ramirezfranciscof two minor things. Already approve if it is intentional and don't want to change it, but otherwise I will quickly reapprove after you addressed it.
echo.echo_success('migration completed') | ||
@click.pass_context | ||
@decorators.deprecated_command( | ||
'This command has been deprecated and will be removed soon (in v3.0). ' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional that this will be removed in 3.0 and the rest in 2.1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is intentional. I personally would prefer to leave the deprecations for longer (not sure if until 3.0, but probably more than 2.1 since I suspect this will be out relatively soon), but this is what was agreed in the last meeting (see notes).
BTW: I'm still not convinced about exposing this information to the user since this is mostly for internal reference (i.e. remembering when to take it out), but I didn't know where else to track this since the .. deprecated:: vA.B.C
addition to the docstring is for recording when it was deprecated and not up to when. Any suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree that it is for internal remembering. Since it affects the user exactly when it is going to be removed, it seems like very relevant information for them. Only thing missing is when the version that it will be removed in is expected to be released.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go for me, thanks @ramirezfranciscof
Thanks a lot for the review @sphuber ! |
The following specific commands were moved:
integrity: the checks that were performed here are no longer relevant.
There will be a new verdi storage integrity that will perform more
general checks (once the features of the repository are implemented).
migrate: moved to
verdi storage migrate
.summary: information now available through
verdi storage info
.version: information now available through
verdi status
.The respective tests were adapted as well.
closes #5226