rsalmei / alive-progress

A new kind of Progress Bar, with real-time throughput, ETA, and very cool animations!
MIT License
5.53k stars 206 forks source link

ETA as Input (Feature) #89

Closed jacobian91 closed 2 years ago

jacobian91 commented 3 years ago

I may have missed it, but I haven't been able to find this functionality in main or 2.0.

We have a case where we have a long single step (HTTP post). Currently in main I'm trying an unknown spinner, and adding the title "ETA 50seconds". It would be great to input an ETA like: with alive_bar(eta=50,...) as bar:

TheTechRobo commented 3 years ago

That makes sense, since sometimes you don't want alive-progress to handle it, and also unknown mode can still work with it, for example if it is searching through directories, it might be done 90% of the changes and you can assume that it is only a small amount of time left (relatively), and so even in unknown mode ETA can be useful. Agree fully!

jacobian91 commented 3 years ago

Another feature would be to add the ability to make a standard progress bar (not an unknown spinner) and make it purely time-based and need to call bar() only once.

rsalmei commented 3 years ago

I'm not sure I understand this, care to explain it better?

jacobian91 commented 3 years ago

The main idea here is that when something is a single line in the python code, I don't have a loop that I can repeatedly update a progress object with, e.g. making a call to bar(). So instead I need to use an unknown spinner, but I actually do know about how long the code should take to execute. So if there was a way to allow the progress bar to be purely time-based, there would not be repeated calls and alive-progress would just update it with how much time has elapsed vs how much time is estimated.

For example, I have a process that takes 2mins, and I want the user to know the application isn't frozen or stuck. If I use an unknown spinner, they may get bored of watching it spin and think it is broken. But I don't have a loop to repeated call bar() with to update a standard progress bar. So instead, I would like to see a progress bar that looks like a standard bar but increases its progress based on the estimated time remaining. If the time goes past the estimated time, the user could use that as a hint that something may not be working and could stop it then.

rsalmei commented 3 years ago

Humm, now i got it! But it seems you could easily do this with manual mode, couldn't you? Something like:

step = 1 / eta_seconds
current = 0
with alive_bar(eta_seconds, manual=True):
    for _ in range(eta_seconds):
        time.sleep(1)
        current += step
        bar(current)

It will even show when it overflowed, if the time expires... Wouldn't that work for you?

jacobian91 commented 2 years ago

The problem with manual mode is I still have to call bar() multiple times. A simple example of my use-case would be where a single line of python code is called that takes time to complete and only is called once, e.g. a subprocess call to 'timeout'.

import subprocess
eta_seconds = 5
with alive_bar(eta_seconds):
    subprocess.run(['timeout','5'])
rsalmei commented 2 years ago

I don't see any problem in calling bar() multiple times. Remember this is the way to make the bar go forward. I think it'd be very weird to make a progress bar update itself automatically. Any progress bar change should always be a response from an active call by the user.

In your case, I'd create a background thread, and display a cool alive-progress being updated every second. You could use the definite mode as usual, and increment it until the desired time, or even better, you could use the manual mode to make it backward from 50 to 0, clearly indicating to the user it is the expected time remaining!

Can't make much more than this man. Hope it works! 👍