Add option to suppress progress bar in train log output
Author: cohml
Pull request: no
Labels: name: trainer

name: Feature request

### Feature request

When training a transformer model with `transformers` - certainly using the `Trainer.train` API but probably also with other methods as well - a `tqdm`-style progress bar is printed to the screen.

This is very useful when monitoring training in the terminal in real time. But it really messes up logging when this output is piped to a file.

This is because the progress bar appears to use the carriage return character to give the illusion of refreshing the bar, but that character wreaks havoc when trying to `cat`, `less`, or `grep` through a file.

Here's an example of what I mean:

```bash
❯ grep -c eval_mse train.log
85
❯ grep eval_mse train.log
100%|██████████| 850/850 [1:41:01<00:00,  4.69s/it]{'eval_loss': 0.6620487570762634, 'eval_mse': 0.8136637373073005, 'eval_qwk': 0.7408296916568654, 'eval_runtime': 15.4491, 'eval_samples_per_second': 43.239, 'eval_steps_per_second': 2.719, 'epoch': 49.41}
{'eval_loss': 0.6605485081672668, 'eval_mse': 0.812741345170533, 'eval_qwk': 0.7413115848125768, 'eval_runtime': 15.2233, 'eval_samples_per_second': 43.88, 'eval_steps_per_second': 2.759, 'epoch': 50.0}```
```

This shows that my log file has 85 lines with the substring `eval_mse`, but when I try to view the individual lines themselves, the carriage returns eats almost all the output.

Meanwhile, manually replacing those characters shows all the matches (only last 5 shown here for brevity):

```bash
❯ sed 's/\r/\n/g' train.log | grep eval_mse | nl | tail -5
    81	 96%|█████████▋| 820/850 [1:37:14<03:08,  6.27s/it]{'eval_loss': 0.6764867305755615, 'eval_mse': 0.8224881544548046, 'eval_qwk': 0.7378055733442015, 'eval_runtime': 14.7125, 'eval_samples_per_second': 45.404, 'eval_steps_per_second': 2.855, 'epoch': 47.65}
    82	 98%|█████████▊| 830/850 [1:38:24<02:07,  6.36s/it]{'eval_loss': 0.6555904746055603, 'eval_mse': 0.8096854324958218, 'eval_qwk': 0.7447225139461018, 'eval_runtime': 14.7862, 'eval_samples_per_second': 45.177, 'eval_steps_per_second': 2.84, 'epoch': 48.24}
    83	 99%|█████████▉| 840/850 [1:39:47<01:48, 10.82s/it]{'eval_loss': 0.6539692878723145, 'eval_mse': 0.8086836641571903, 'eval_qwk': 0.744001775888472, 'eval_runtime': 14.8626, 'eval_samples_per_second': 44.945, 'eval_steps_per_second': 2.826, 'epoch': 48.82}
    84	100%|██████████| 850/850 [1:41:01<00:00,  4.69s/it]{'eval_loss': 0.6620487570762634, 'eval_mse': 0.8136637373073005, 'eval_qwk': 0.7408296916568654, 'eval_runtime': 15.4491, 'eval_samples_per_second': 43.239, 'eval_steps_per_second': 2.719, 'epoch': 49.41}
    85	{'eval_loss': 0.6605485081672668, 'eval_mse': 0.812741345170533, 'eval_qwk': 0.7413115848125768, 'eval_runtime': 15.2233, 'eval_samples_per_second': 43.88, 'eval_steps_per_second': 2.759, 'epoch': 50.0}
```
This kind of thing has inconvenienced me many times. So it would be very nice and make the logging more readable when captured via a pipeline if this progress bar could be optionally disabled.

### Motivation

The motivation for this feature comes from training scenarios where the logging output is captured in a file or other log stream that persists. The progress bar is hlepful for watching training in real time. However once an experiment is finished, if the logging output is stored for future consultation, the progress bar just becomes an obstacle to work around. So if users could opt out of it, that would be great.

### Your contribution

I would love to contribute a solution here, but the `transformers` code base is so vast that I have no idea where to begin. If a core dev could provide some pointers to help get me started, that would be much appreciated.

Comments:
@cohml 
have you tried adding the `disable_tqdm` parameter to your `TrainingArguments` ? 

you can read more about it here : https://huggingface.co/docs/transformers/v4.37.1/en/main_classes/trainer#transformers.TrainingArguments.disable_tqdm

Oh man, that's exactly what I was after! Thanks so much @not-lain for pointing it out! I will close this issue now.