-
Notifications
You must be signed in to change notification settings - Fork 37
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
Optionally display progress bar in print_status #602
Comments
@joaander Thanks for the issue. Disabling the progress bar might lead to several seconds or even minutes of no output in the terminal when dealing with status checks over large workspaces. I believe we found the lack of output confused users and caused them to kill the process in early prototypes (or not realize that they had written expensive status checks). Would it be okay to leave the option enabled by default and allow users to opt out with edit: I was mostly speaking about the CLI above but you referred to the Python API - please feel free to clarify if you see or expect any differences in the behavior between these two. Can you also give more context about the Jupyter exception you’re seeing and what special configuration is needed to resolve it? |
I'm fine with either option as a default, though I would find it confusing if When I first tried
|
The notebook issue is partially caused by #371. tqdm has an automatic mode that detects if it is in a notebook, and shows an HTML progress bar instead of a console one (the console format doesn't render very well in the notebook, I have sometimes seen the |
Given the state of this issue, I believe we can try to fix this behaviour by defaulting to not showing a progress bar when people use the Python API. What do you suggest? |
Summarizing the discussion so far to make sure that we're all on the same page:
|
I agree with that overview. On the last point, I’d say progress on by default in CLI and progress off by default in the Python API would match my expectations as a user for each interface. CLI users also have more direct control of stdout and stderr than Python users, if we differentiate progress bars (stderr) and program output (stdout). I believe that’s how the output works currently but I’m not 100% sure. |
By default, we don't show progress in |
I don't think we need to do any deprecation cycles to change the default behavior of a progress bar. The addition of a deprecation message would be a more disruptive change than just adding/removing the progress bar in my opinion. |
Definitely no need for a deprecation cycle. |
In light of the above discussions, I'm proposing the following as the action items to close this issue:
|
What line(s) in I see Lines 2258 to 2265 in b4d870e
but I don't see where this is called with tqdm_kwargs != None .
|
@joaander I think what you're looking for is this line: https://github.com/glotzerlab/signac-flow/blob/master/flow/project.py#L2671. The |
Thanks. It appears from this code that making progress bars optional is not a trivial change. |
I think it would require the following:
|
Feature description
I would like to hide the progress bar output generated by
FlowProject.print_status
.Proposed solution
Add the argument
progress
to the signature ofFlowProject.print_status
with a default value ofFalse
. Users should opt-in to additional output when desired.Additional context
The proposed solution follows that in
FlowProject.run
which has the default argumentprorgress=False
.The progress bar is a significant amount of the total output for small workspaces and provides no benefit to users for small workspaces. Additionally, using
print_status
in Jupyter notebooks requires special configuration or elseprint_status
fails with an exception. New users running tutorials for the first time may be frustrated troubleshooting issues like this.The text was updated successfully, but these errors were encountered: