Add ability for TQDMProgressBar to retain prior epoch training bars (…

[jojje]

What does this PR do?

Adds the ability to retain tqdm progress bars from prior training epochs.

Fixes #19322

Before submitting

• Was this discussed/agreed via a GitHub issue? (not for typos and docs).
  A: No, an issue was was opened but there is no PR yet to discuss (catch 22).
• [ X ] Did you read the contributor guideline, Pull Request section?
• [ X ] Did you make sure your PR does only one thing, instead of bundling different changes together?
• Did you make sure to update the documentation with your changes? (if necessary)
  A: Yes.
• Did you write any new necessary tests? (not for typos and docs)
  A: No. The goal was to not break any existing behavior so the existing TQDMProgressBar test suite was used to ensure that objective.
• [ X ] Did you verify new and existing tests pass locally with your changes?
  A: Partly, I only ran the TQDMProgressBar test suite, since the other's mostly failed on my machine even before the change was made. As such am submitting a draft PR to ensure the entire test suite passes using the project's CI system before it's worth discussing the PR.
• Did you list all the breaking changes introduced by this pull request?
  A: N/A, No breaking changes intended.
• Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors):
  A: Yes

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist

• Is this pull request ready for review? (if not, please submit in draft mode)
• Check that all items from Before submitting are resolved
• Make sure the title is self-explanatory and the description concisely explains the PR
• Add labels and milestones (and optionally projects) to the PR so it can be classified

---

📚 Documentation preview 📚: https://pytorch-lightning--19578.org.readthedocs.build/en/19578/

[awaelchli]

Sounds like a good idea!

[awaelchli]

Instead of doing this, I believe it would be better to pass leave=self.leave to the tqdm bar directly (see init_train_tqdm(), init_validation_tqdm() etc. above.

[jojje]

You mean creating yet another constructor wrapper, like in the rich progress bar, and what is already present in this file?

E.g.

    def reinit_train_tqdm(self) -> Tqdm:
        """Override this to customize the tqdm bar for training."""
        return Tqdm(
            desc=self.train_description,
            position=(2 * self.process_position),
            disable=self.is_disabled,
            leave=self._leave,
            dynamic_ncols=True,
            file=sys.stdout,
            smoothing=0,
            bar_format=self.BAR_FORMAT,
        )

It'd be identical to init_validation_tqdm, so I don't really see the point of that, unless the intended introduction of init_validation_tqdm had some undocumented purpose that you're planning to start taking advantage of (and perhaps need to change the implementation of the constructor function)

Or did you perhaps mean changing the hard coded "leave=True" to "leave=self._leave" in the existing "init_train_tqdm" function. Or perhaps a third variant, where the init_train_tqdm function is parameterized to take the leave value?

PS. Thanks for the review.

[awaelchli]

No, I'm proposing to simply pass leave=self.leave in init_train_tqdm() where we hard coded it to True so far. Line 205