-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
remote: use progress bar when paginating #3532
Conversation
minor: NO_TOTAL progress bar still looks very similar to the regular one, I first thought there is a bug - wondering if this format could be improved to make it more explicit? cc @casperdcl |
awesome stuff, btw, @pmrowla ... thanks for taking care of UI here! |
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.
Nice, er, progress!
@@ -691,7 +691,7 @@ def path_to_checksum(self, path): | |||
def checksum_to_path_info(self, checksum): | |||
return self.path_info / checksum[0:2] / checksum[2:] | |||
|
|||
def list_cache_paths(self, prefix=None): | |||
def list_cache_paths(self, prefix=None, progress_callback=None): |
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.
unused?
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.
progress_callback
is unused in ssh and local remotes, but the parameter was added to both so that overridden list_cache_paths()
in ssh/local still match the abstract method defined in RemoteBASE.list_cache_paths()
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 but presumably it should be used now that it's added?
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.
both local and ssh have their own overridden cache_exists()
implementation and neither one uses list_cache_paths()
at all during cache_exists()
. The only time list_cache_paths()
would get called for either local or ssh remotes would be for RemoteBASE.all()
during a dvc gc
call.
all()
does not currently display any progressbars at all, but now that I'm thinking about this, it probably should
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.
indeed; though I'm not sure in principle about having a function exists which takes a non-null progress_callback
and ignores it. This implies a bar will be displaying hanging at 0% on screen and then eventually suddenly disappear.
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.
list_cache_paths()
for local and ssh have been updated to use progress_bar
(if it is set) to keep them consistent with the other remotes. A separate issue (#3543) has been filed for updating the dvc gc
/RemoteBASE.all()
behavior and will be addressed in a follow-up PR.
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.
btw just to clarify - every time I've said "unused?" it's more a reminder to address at some point (could be in a future PR) rather than an expectation to address in this PR.
- add `progress_callback` parameter to `list_cache_paths()` so that remotes can update remote cache traverse progress bar after fetching a page
minor fixes/tidy
- keep ssh/local consistent with other remotes (even though `dvc gc`/`RemoteBASE.all()` do not currently use progress bars)
The estimation progress bar still looks similar to the remote cache query progress bar, but given that the estimation status is just calculating the initial and total values for the cache query progress bar, it seems ok to me. I'm not sure if it would make much of a difference to the user whether the estimation and main cache query appears to be a single operation or as two explicitly distinct operations. |
do you mean that it looks like an actual progress bar but in this case we don't show any progress? |
from what I see from code we do show actual progress now, right? so, what is your concern, Peter? they are similar, and it looks totally fine to me ... may be I'm missing something. |
yes, I see, it doesn't indeed show the progress itself - it's impossible since we don't know what the size is, right? we'll be able to do this though when we implement the short cutting in your other PR? at least we'll have an upper bound of how many page we want to go through is there some other quick style we can apply - like spinner or something? |
Yes, after the short-cutting PR we would have an upper-bound for the |
@pmrowla make sense, yep. @casperdcl is there a spinner-like mode for TQDM? :) It looks like it's a bit more general problem that we should probably solve in a separate PR? looks like we just need a UX component for such cases, most likely we'll have more applications for it. @pmrowla @efiop what do you think? I believe there are lot of project we can even use (though we wan't be able to show units in a nice way?) - https://github.com/pavdmyt/yaspin. That's why it would be great to have a mode like this in TQDM itself. |
dvc/remote/base.py
Outdated
self.list_cache_paths( | ||
prefix=prefix, | ||
progress_callback=lambda n=1: pbar.update( | ||
n * total_prefixes | ||
), | ||
), |
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.
Would extract this into a separate var and use it instead. There are too many levels of brackets in this set(map(... line , which makes it really hard to reat it π Same down below.
dvc/remote/base.py
Outdated
list( | ||
self.list_cache_paths( | ||
prefix=prefix, progress_callback=pbar.update | ||
) | ||
), |
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.
let's move list
into a separate variable and then map(self.path_to_checksum, paths)
. Just to make it easier to read π
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.
Looks good! @pmrowla please check my two nitpicky comments above and feel free to merge. The questions discussed earlier could indeed be solved later with the followup PR, I agree with @shcheklein . I'm eager to unblock #3537 π
@shcheklein there's no spinner mode but I think the "no total" progress stats are much better than a spinner. I guess you'd like both the stats and a spinner? The updating stats function as a spinner to me :) |
@casperdcl yep, I agree that it's definitely not critical! ... like I mentioned, the only reason for my concern was that since they are so similar and happen one after another, you kind-a expect to see progress happening (visual part of it - where it's emptiness now) - but when you don't see it you start asking yourself a question - is still at 0% π± :) Maybe just let it align the stats close to the text? To make it more explicit that visual part is not expected. |
no strong opinions here |
β I have followed the Contributing to DVC checklist.
π If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here. If the CLI API is changed, I have updated tab completion scripts.
β I will check DeepSource, CodeClimate, and other sanity checks below. (We consider them recommendatory and don't expect everything to be addressed. Please fix things that actually improve code or fix bugs.)
Thank you for the contribution - we'll try to review it as soon as possible. π
BAR_FMT_NOTOTAL
progress bar, as current # of estimated total remote sizeWill close #3526