Provide option to force progress bars to display on non-TTY outputs about indicatif HOT 15 OPEN

Duplicate of #86

from indicatif.

Perhaps there's been some evolution since this and #86 were posted, but I can't see a sensible way to force progress bars to display on non-TTY outputs? Perhaps this issue should be re-opened?

console::Term::is_term is called here to determine whether to draw: https://github.com/mitsuhiko/indicatif/blob/16e755cd17570b95adff7d22c00c36b8014cd3e9/src/draw_target.rs#L128

which in turn calls isatty:
https://github.com/mitsuhiko/console/blob/663ccc18bfb161b7e5a12bf302ad2b2b28c380a7/src/unix_term.rs#L18

No obvious way to override this? My use case is I'd like pb.on_finish(indicatif::ProgressFinish::AndLeave) to appear when run under CI, so we can get a measure of elapsed time, bytes_per_sec, etc.

from indicatif.

I'm open to merging something like that. If you're willing to work on this, maybe write up a brief design of how this might be integrated, I'll review that and then we can work on a PR?

from indicatif.

Also looking forward to this feature. I'm running my program in Jenkins, but Jenkins redirects stdout and stderr to a file, causing the progress bar in the program to be hidden. Expect an option to force display.

I tried modifying is_hidden in src/draw_target.rs to always return false, but it still doesn't work.

update -----

Removing the if statement in drawable of draw_target.rs works fine for me.

                if !term.is_term() {
                    return None;
                }

But there is another issue that if using tail -f ouput to see redirected log, it's fine. The progress bar looks fine.
In the redirected file, it looks like below.

from indicatif.

@djc I am writing a web-app with axum where the server runs a command (this command displays an indicatif progress bar), and I want to show the progress bar to the client through a websocket. I think that this issue is currently a blocker for my application, right? Or is there currently a way to achieve my goal that I am missing?

I would be happy contribute and make this happen, but I have no idea how any of this works. Can I get some pointers on what are the issues that need to be fixed for something like this to be possible?

from indicatif.

So far indicatif has been quite geared towards CLI applications so it feels like your proposed use case is quite a bit removed from being in the sweet spot. Why do you feel indicatif is a good fit for your app? Are you using some dependencies that already offer an indicatif integration? I wonder if we might want to somehow split out some of the existing API so that it could be usable in a scenario like this.

from indicatif.

Hi @djc. It's not so much the fact that I think indicatif is a good fit for my app, but more the fact that I already have a CLI application that uses indicatif and I want to launch it from a web page (and show it's progress to users).

I work in a lab with people all over the world and they currently have to SSH to one of our computers and run my CLI program to analyze data. Some people (understandably) don't know how to do any of this, so I want to offer a website with a simple UI that literally just launches this CLI app in the server and shows some progress (these are long-running processes, so it would be confusing to not show progress).

Its my first time working on something like this, so I might be thinking about this in the wrong way (?). I also saw some some issues like #525. Maybe something like that would make more sense for my use-case? Send JSON status through a websocket and render a progress bar on the browser with javascript?

from indicatif.

Thanks for the context, that makes a lot of sense! In your CLI app, how hard would it be to extract progress tracking to avoid relying on indicatif (for the web frontend at least) -- is indicatif deeply integrated, or is there a simpler way to extract the state of progress for your application?

from indicatif.

I have a simple CLI like this one where the progress is just a single loop counting how many files I have gone through.

And I have another more complex one like this one with multiprogress bar and rayon parallel iterator increasing one of the the progress bars.

from indicatif.

I think what might work for this is to provide a custom (noop) TermLike to ProgressDrawTarget::term_like().

from indicatif.

I am not sure I understand how that helps.
If I understand correctly, your suggestions is that I add a struct NoOpTerm to my CLI where all TermLike methods literally do nothing? Then I create my ProgressBar/MultiProgress with_draw_target(None, no_op_term)?

What does this change for me? What can I send now to the user through the websocket to display the progress?

from indicatif.

from indicatif.

I am not sure I understand how that helps. If I understand correctly, your suggestions is that I add a struct NoOpTerm to my CLI where all TermLike methods literally do nothing? Then I create my ProgressBar/MultiProgress with_draw_target(None, no_op_term)?

What does this change for me? What can I send now to the user through the websocket to display the progress?

Okay, well, you might want to forward to InMemoryTerm instead and try to extract its contents into something that's readible for your client application?

from indicatif.

Ok, I think that InMemoryTerms contents might work for me. I think that (at least for my simplest CLIs) I can force the contents of the InMemoryTerm to e.g. stdout every iteration of the loop, and then just send that to the client side. Right?

If the above works, I can probably do something similar with my more complex progress bars.

Thanks a lot :)

from indicatif.

Ok, I think that InMemoryTerms contents might work for me. I think that (at least for my simplest CLIs) I can force the contents of the InMemoryTerm to e.g. stdout every iteration of the loop, and then just send that to the client side. Right?

Something like that, I suppose -- I think the details depend on how your web service is wired up to the CLI.

from indicatif.