-
Notifications
You must be signed in to change notification settings - Fork 203
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 archive progress bar #4504
Refactor archive progress bar #4504
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #4504 +/- ##
===========================================
- Coverage 79.36% 79.36% -0.00%
===========================================
Files 475 476 +1
Lines 34907 34950 +43
===========================================
+ Hits 27701 27733 +32
- Misses 7206 7217 +11
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Hi @chrisjsewell, before going through the code in detail, here is a question: There is an open PR #3896 to homogenize verbosity handling across the whole verdi cli. I am wondering whether a similar approach would not work for the progress bar as well. |
Eurh, I think exactly the opposite; I think singleton's (and using mutable global variables in general) are awful and should only be used when absolutely necessary. I would point you, for example, towards https://stackoverflow.com/a/138012/5033292, https://stackoverflow.com/a/2663030/5033292 etc, for the multiple issues with the singleton design pattern Basically I would advocate dependency injection over the singleton design pattern |
if anything, the private functions in this class + the |
I think, as with many questions, there is a balance to be found. Using loggers is a standard approach suggested in the official python tutorial https://docs.python.org/3/howto/logging.html#configuring-logging In any case, I agree that the progress bar (which is around only temporarily and specific to this section of hte code) differs from loggers (which are assumed to be there all the time), so perhaps we will need to pass it around in the end.
Yes, a more localized way of sharing state would make sense. |
Well loggers are one of them rare use cases. Although still it can be a real pain to ensure the behaviour of logging, for example sphinx sets up a global logger which makes debugging failed tests a real annoyance (docutils/sphinx also have some other singletons which are horrible to override, and one of the reasons for my hatred of them lol). |
Just to note, none of the public functions require that a progress bar be specifically passed |
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 @chrisjsewell
only minor comments
) | ||
res = set(builder.all(flat=True)) | ||
given_log_entry_ids.update(res) | ||
total = 1 + ((1 if include_logs else 0) + (1 if include_logs else 0) if node_ids_to_be_exported else 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.
that should probably be
total = 1 + ((1 if include_logs else 0) + (1 if include_logs else 0) if node_ids_to_be_exported else 0) | |
total = 1 + ((1 if include_logs else 0) + (1 if include_comments else 0) if node_ids_to_be_exported else 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.
by the way, if there are no node ids to be exported, what is the 1
for?
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.
oops, yeh I was having an issue without the 1, but I will re-check
@ltalirz inspired by the discussion in #3896, I have re-re-factored in a54c319! The progress bar is once again a singleton, but now it is fully generalised to just the concept of a progress reporter. As such it is not specific to importexport and so I have added its code as Control of setting the progress reporter is now moved to the CLI (perhaps it could somehow be integrated into #3896?), the exporter functions just retrieve it, with the default being a "null" reporter. For now aiida/tools/importexport/common/progress_bar.py remains, but in the import refactor, this should be removed |
Note there is some code to set/reset the logging level in the |
|
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.
Hi @chrisjsewell , thanks for putting more thought into this an coming up with this solution.
I have some questions concerning the interface before finishing the review; will get back to the laptop later tonight
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 @chrisjsewell ; mostly requests for documentation + one simplification
aiida/common/progress_reporter.py
Outdated
|
||
Example Usage:: | ||
|
||
with progress_reporter(total=10, desc="A process:") as progress: |
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 this supposed to be progress_reporter_base
?
@ltalirz in 1ab807a I have re-written the progress reporter contextmanager as a single class. I have also added the |
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 @chrisjsewell , at least to me this version of the progress reporter is much more obvious to interact with.
Let's merge this :-)
Edit: After the tests pass ;-)
As proposed in #4053 (comment), this PR refactors the progress bar implementation in for the archive export to remove the singleton approach and make all calls to the progress bar a context manager.
I also improved some progress bars to give better feedback (in particular the entity field collection).
I've tested this implementation (see below) and find no issues.
As an added bonus, I have also added a verbose option to the CLI (-v), such that this will set the progress bars to be left on screen (i.e.
leave=True
)