Make the ProgressBar class API

[pombredanne]

@mitsuhiko The click._termui_impl.ProgressBar is a wonderful and magical piece of code.

There are cases though where subclassing this can be needed such as providing a few defaults progress messages such as on enter or exit of the context manager for intro and summaries.

This is especially useful to avoid otherwise naughty code mixing progress reporting and actual processing

Nothing prohibits this of course, but if it were made API, subclassing would benefit from a tad more stability with new upgrades. The overall interface of the class has been rather stable for about one year now with only a minor change to support manually updating more than one step at a time....

So IMHO this would benefit to be exposed in a non _ underscore module.

[pombredanne]

BTW the code I am using this in is here https://github.com/nexB/scancode-toolkit/blob/e3b57934a0d6e41a7e3ee6e8261912d3b91764cb/src/scancode/utils.py#L64

It is rather nasty and tangled and under heavy refactoring to be cleaner and less spaghetti like ... ;)

[flying-sheep]

i’m 👍ing this!

i just made the progressbar abstraction smart-progress, which i at first wanted to base on tqdm, but which now relies on that class.

sadly that means relying on an undocumented, private API.

from my usage you can maybe derive what a more general interface would need. IMHO:

• it’s already pretty awesome to extend. apart from ignoring a few parameters/fields, i basically just have to override __enter__, render_finish, and render_progress.
• I’d suggest to create a render_start method and call that instead of render_progress in __enter__.
• also please extract this and this part into a info_bits or format_info_bits method/property which would allow to easily use the information in without copying code from format_progress_line

thank you very much!

[flying-sheep]

@pombredanne your link is broken. protip® from github: press y to get a canonical link to a commit that will never break by changing master

[untitaker]

I recall Armin mentioning one time that he is fundamentally unhappy with the ProgressBar API.

[flying-sheep]

well, it’s still easily extensible and its functionality is too useful not to use.

and being able to either use iteration or the update method is also very useful.

[pombredanne]

@flying-sheep link updated
You can see there an enhanced progress bar, a more verbose progress logger and a noop progress bar (displaying nothing). The three are then used to display more or less based on command options.

https://github.com/nexB/scancode-toolkit/blob/e3b57934a0d6e41a7e3ee6e8261912d3b91764cb/src/scancode/utils.py#L64

[flying-sheep]

also useful would be feature detection if the shell can do unicode and then go to a finer-grained bar like this.

that would also benefit from a more flexible format_progress_line. e.g. by adding a format_bar method that can be overridden

[mitsuhiko]

I think it would be nice if people could experiment around with it somewhere else and when we found a better way, we redo it in click. I'm not super happy with how it works.

[flying-sheep]

could you voice your problems with it?

[davidism]

ProgressBar's implementation is pretty messy. It works, but there are better solutions out there, such as tqdm. For now I'd rather not elevate its API more than is already documented.