I know I added a progress bar for use in notebooks. But it seems unused currently. I'm also pretty sure there was a terminal based one at some point, but I'd have go hunting git history.

I think this needs a broader discussion. Maybe we should look for places in pyMOR where this would be useful. Regarding implementations, I myself have enjoyed using tqdm, which supposedly also works with jupyter.

Using tqdm would require installing another package. Maybe we can write a less advanced and simpler progress bar instead of relying on additional external code.

I would assume that it is quite non-trivial to write a progress bar that reliably works in all terminals. If it's more like 20 lines of code, I see no reason to reinvent the wheel here. Also, tqdm has 15k stars on github. It's not going away any time soon.

That's true.

Maybe we can make tqdm optional and not mandatory?

Maybe we can make tqdm optional and not mandatory?

How would that work. You mean that the entire progress bar is optional and does not appearch when tqdm is not installed, or do you want an alternative implementation for that case?

Right, if tqdm is not installed, no progress bar shows up. This way, we would not force installing tqdm, but provide a progress bar in the case it is installed.

I think we should be careful with using progressbars in the library proper. I often have to look at combined stderr/out stream "logs" from a queue system for example. These would look horrible with progress bars in them. Same for CI logs. So if they were to be used, I must be able to turn them off at least globally (forcing me not to have tqdm installed is not an option).

Usage in in demos/tutorials is ofc fine and I think a great idea.

@renefritze do you know how tqdm behaves in this case? Maybe it is smart enough to see that it is not connected to a proper terminal?

Usage in in demos/tutorials is ofc fine and I think a great idea.

I think it is more interesting to discuss whether or not to use this inside of pyMOR's algorithms (e.g. gram_schmidt).

Right, if tqdm is not installed, no progress bar shows up. This way, we would not force installing tqdm, but provide a progress bar in the case it is installed.

That would be a possibility, but also some extra work since we would need to duplicate all parts of tqdm's API we want to use. If it is really needed to disable the functionality (e.g. for @renefritze's use case) that would be reasonable. I would not do it just to make one dependency optional.

Regarding redirection see Using tqdm when redirecting output?. Sounds like @renefritze will not think of this as a satisfying solution?

Maybe it is smart enough to see that it is not connected to a proper terminal?

At least with slurm it would actually be connected to a proper terminal. Ofc it could still be smart enough to detect the runtime env through some other means. I haven't actually used tqdm at all.

Sounds like @renefritze will not think of this as a satisfying solution?

Correct. Most of the time I do not use redirection inside the queue script since the manager does that for me, and better. With per Rank logfiles and such.

I would not do it just to make one dependency optional.

Agreed. It's a pure python package with no external deps itself too. So I think the barrier for extra work to keep tqdm entirely optional is super low.

That would be a possibility, but also some extra work since we would need to duplicate all parts of tqdm's API we want to use.

Why do we need to duplicate code of tqdm in that case? Couldn't we just check whether tqdm is installed as we do with, for instance, FEniCS and use a progress bar if tqdm is available?

Our to-be tdqm shim would need to be able to accept all calls tdqm can. Otherwise we'd need to implement that check (and fork code paths accordingly) everywhere we want to use tqdm instead of just once.

Edit: "all" is too much though. "enough" as in what we actually want to use.

Alright, I see.

Typer seems to also support progressbars: https://typer.tiangolo.com/tutorial/progressbar/

Typer seems to also support progressbars: https://typer.tiangolo.com/tutorial/progressbar/

However, it does not seem to be able to estimate time till completion. I think this is a very useful feature tqdm has ..

I'll throw the rich implementation into the ring.
pip's using it since version 22
It looks good in logfiles.
I like rich 😉

I'll throw the rich implementation into the ring. pip's using it since version 22 It looks good in logfiles. I like rich wink

Looks, good! In particular the latter is appealing!

A first version using rich is implemented here for the neural network training. You can check it out by running one of the neural network demos.