progress bars can be disabled

[oliverdain]

It would be nice to be able to disable the progress bars you see with lakectl local clone and other bulk operations.

Use case: I have some ML training jobs that run in a Kubernetes cluster. That cluster has logging set up so anything a container logs gets sent to an external logging service. Those services typically expect logs to be in a pretty simple format like 1 line per thing logged or in JSON format. However, the progress bars use special characters (e.g. \r) to update the cool little graphs and that confuses the heck out of the log parsers. It's still nice to have logs like downloaded some/file.txt but the progress bars are problematic. Ideally you'd detect that the lakectl stdout isn't a terminal and if that's the case convert the progress bar logs to "regular logs". If that's not possible a flag like --disable-progress would be great.

[oliverdain]

Thanks for doing this. It's an improvement but I don't think it really fixes the issue. If you pass --no-progress it doesn't display the ### animations anymore but it does still use \r and \n characters to update the output. For example, initially it might display something like:

download vet-video-labels/clljmlh8j0z5q~ ... 
download vet-video-labels/clljmnw6f113m~ ... 
download vet-video-labels/clljmdchw2ppv~ ... 
download vet-video-labels/clljmjdop2qtg~ ... 

But then, later, it moved back up a few lines to update the display to:

download vet-video-labels/clljmlh8j0z5q~ ... done!
download vet-video-labels/clljmnw6f113m~ ... done!
download vet-video-labels/clljmdchw2ppv~ ... 
download vet-video-labels/clljmjdop2qtg~ ... 

Most logging solutions (e.g. Google Cloud Logging, DataDog, SigNoz, etc.) assume a log message is a single line . That is, it expects a string of unicode characters terminated by a \n. Once it sees the \n that's the log message that gets stored. When the progress messages use meta-characters to move back upwards in the terminal to update existing lines those are new log lines and they're very hard for the likes of DataDog, Cloud Logging, etc. to parse.

I'd like to request that this get re-opened and --no-progress should mean no "updating display" - just log downloading X and then, when the download is complete, log X download complete (or something like that).

[N-o-Z]

Thanks for doing this. It's an improvement but I don't think it really fixes the issue. If you pass --no-progress it doesn't display the ### animations anymore but it does still use \r and \n characters to update the output. For example, initially it might display something like:

download vet-video-labels/clljmlh8j0z5q~ ... 
download vet-video-labels/clljmnw6f113m~ ... 
download vet-video-labels/clljmdchw2ppv~ ... 
download vet-video-labels/clljmjdop2qtg~ ... 

But then, later, it moved back up a few lines to update the display to:

download vet-video-labels/clljmlh8j0z5q~ ... done!
download vet-video-labels/clljmnw6f113m~ ... done!
download vet-video-labels/clljmdchw2ppv~ ... 
download vet-video-labels/clljmjdop2qtg~ ... 

Most logging solutions (e.g. Google Cloud Logging, DataDog, SigNoz, etc.) assume a log message is a single line . That is, it expects a string of unicode characters terminated by a \n. Once it sees the \n that's the log message that gets stored. When the progress messages use meta-characters to move back upwards in the terminal to update existing lines those are new log lines and they're very hard for the likes of DataDog, Cloud Logging, etc. to parse.

I'd like to request that this get re-opened and --no-progress should mean no "updating display" - just log downloading X and then, when the download is complete, log X download complete (or something like that).

Hi @oliverdain thanks for the detailed information.
We don't usually reopen issues which are linked to a PR that was already merged.
Would you mind opening a new issue with this information and we'll take a look at it?
Thanks,

[oliverdain]

I opened #8111