Use and abuse of ProgressBars

I am trying to use ProgressBar in a non-standard manner and would like some advice on how to proceed.

First, my use case does not really lend itself to wrapping an iterable like ProgressBar wants. Instead, I monitor an external process which tells me how many stages there are and how many "things" each stage has to do and how many have been done. Sometimes, the number of things to do in a stage is known at the beginning and sometimes it needs to be calculated and is reported later. Additionally, in some, extreme cases, a stage gets restarted and its number of things done gets reset back to 0.

I am currently handling this by creating a ProgressBarCounter object without a data member. I then set the total and current attributes directly as I receive that information. This works fairly well but I'm sure it's not intended to. One thing that would not work if I used it is the remove_when_done feature. That's because the check for that is done in the __iter__method which I'm bypassing.

Would you please consider supporting this type of use case by converting total and complete to properties that can be set after creation? I can create a pull request if you'd rather I make the changes myself.

Second, there is additional information about each stage that I'd like to display in the progress bar. For example, each stage has a current state (initialized, running, etc.) and a count of things that failed and need to be retried. I can see how to create my own, custom Formatter to do part of this. However, I'd ideally like to save this additional information in the corresponding ProgressBarCounter object.

One way I could do this is to simply add new attributes as needed. Another way is to derive a new class from ProgressBarCounter. If I did that, I'd then have to directly add these new objects to pb.counters because there is currently no API to do so. How do you recommend I proceed? Like above, I can create a pull request if you prefer I go that route.

Finally, while the progress is being monitored, I also receive log messages from the server that I want to display without disturbing the progress bar display. I currently do that by using patch_stdout. That works pretty well but has one, minor, cosmetic issue that happens sometimes.

The typical, progress monitoring goes like this. I receive several logs while the server is setting up the multi-stage processing. I then get the information about the stages and their process. I sometimes get log messages while the stages are running. I then get more log messages at the end of the processing.
Here is the pseudo code for what I'm currently doing:

status = poll()

with ProgressBar(...) as pb:
    with patch_stdout():
        while True:
            if status contains stage progress:
                create or update ProgressBarCounters
            logs = fetch_logs()
            print(logs)
            if status is done
                break
            status = poll()

The minor, cosmetic issue I sometimes see when using the scroll back feature of tmux/screen or xterm is the completed, progress bar is in the middle of the logs like this:

setup logs...
update logs...
old progress bar
final logs...

Ideally, I'd prefer the old, completed, progress bar to no longer be visible at all. Do you know how to make that happen all the time?

Start by reading ProgressBar, ProgressBarCounter, and patch_stdout, focusing on how iter handles remove_when_done and how counters are managed. The issue spans externally updated totals, custom stage metadata, and completed-bar display; done would require a settled API and behavior for these use cases.