[REQUEST] Nested non-local progress bars

[jmetz]

How would you improve Rich?

Add easier non-local nesting abilities for progress bars

What problem does it solve for you?

Quite often one would want to essentially nest progress bars, without explicitly nesting them! For example, I might have a batch job over N files, and for each file I call a function which internally has a for loop I'd also like to track the progress of.

This appears to not be easily doable at present, without passing around Progress instances between functions.

Clearly rich can detect when one attempts to independently construct two Progress instances as I recently found out, getting the error:

rich.errors.LiveError: Only one live display may be active at once.

In such an instance it would be nice if an attempt to create a second, nested Progress instance would instead detect the current live instance and update it's progress group to add the new nested bar. Would this be feasible?

[github-actions[bot]]

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

This is an automated reply, generated by FAQtory

[jmetz]

Presumably somewhere like here:

        self._task_index: TaskID = TaskID(0)
        self.live = Live(
            console=console or get_console(),
            auto_refresh=auto_refresh,
            refresh_per_second=refresh_per_second,
            transient=transient,
            redirect_stdout=redirect_stdout,
            redirect_stderr=redirect_stderr,
            get_renderable=self.get_renderable,
        )

https://github.com/Textualize/rich/blob/master/rich/progress.py#L1089

instead of creating a new Live instance when a Progress initialises, there should be at least the option to try to connect to and update a running Live instance already attached to the console.

[soyams]

getting similar error suddenly.. what its cause?? need suggestion.

[OliverFarren]

This is exactly something i'd like to see possible as well. I'm using the progress bar in a local package to display updates on downloading a file and i'm importing that package into my application where I want to iterate over a series of tasks.

But I can't see a way of having my package create a progress bar that doesn't conflict with the application creating one as well. To my mind this is problematic because were I ever to want to publish a package, it seems that I wouldn't be able to use progress bars or would need to give some options for users to disable them. Is that the case?

[OliverFarren]

Reading through github issues, I guess this relates to #2712 and #146, I've had a look through the discussions/issues.

I guess i'm wondering whether there'd be a way of having it so that when my package starts to create it's progress bar it can check whether a live display already exists and attach itself, without me needing to pass this in.

I can create a minimal example to illustrate my problem if it'd help.

[albertfgu]

👍 , spent some time looking into it and this seems like a large problem when building on top of existing applications that may use rich.