Deprecated LightningLoggerBase in favor of Logger and deprecated loggers/base.py in favor of loggers/logger.py with backward compatibility

[MohammedAlkhrashi]

What does this PR do?

Fixes #11971

• Changed loggers.logger.LightningLoggerBase to loggers.logger.Logger
• Then renamed loggers/base.py to loggers/logger.py.
• Created a new loggers/base.py, which contains LightningLoggerBase with a deprecation warning and subclasses from Logger to support backward compatibility.
• Changed all internal imports to support the refactoring.
• Changed loggers/test_base.py to loggers/test_logger.py
• Created a new loggers/test_base.py to test the deprecation warning from loggers.base.LightningLoggerBase

I still haven't updated the documentation, I first wanted to make sure that I am on the right track and if there are any necessary changes needed.

Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

• Was this discussed/approved via a GitHub issue? (not for typos and docs)
• Did you read the contributor guideline, Pull Request section?
• 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)
• Did you write any new necessary tests? (not for typos and docs)
• Did you verify new and existing tests pass locally with your changes?
• Did you list all the breaking changes introduced by this pull request?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review

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

• 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

Did you have fun?

• Had fun? 😄

[daniellepintz]

@MohammedAlkhrashi Thanks so much for your PR! Mind fixing the merge conflicts and failing tests so we can get this merged?

[MohammedAlkhrashi]

@MohammedAlkhrashi Thanks so much for your PR! Mind fixing the merge conflicts and failing tests so we can get this merged?

Alright 👍 , I will try to fix the conflicts and the failing tests by next week if that's okay.

[daniellepintz]

Awesome, thanks!

[akihironitta]

Could you also update occurrences in the docs?

$ grep -rnI LightningLoggerBase docs
docs/source/extensions/logging.rst:207:You can implement your own logger by writing a class that inherits from :class:`~pytorch_lightning.loggers.base.LightningLoggerBase`.
docs/source/extensions/logging.rst:212:    from pytorch_lightning.loggers.base import LightningLoggerBase, rank_zero_experiment
docs/source/extensions/logging.rst:216:    class MyLogger(LightningLoggerBase):
docs/source/common/lightning_module.rst:996:        # List of LightningLoggerBase objects
docs/source/common/trainer.rst:1755:    # List of LightningLoggerBase objects

[MohammedAlkhrashi]

Hi everyone, I've fixed the merge conflicts, failed tests, and updated the docs accordingly. However, I was wondering if we should also implement wrappers for other functionality in current loggers/base.py for backward compatibility? Such as DummyLogger, or LoggerCollection. Currently, only LightiningLoggerBase is backward compatible if imported directly from 'pl.loggers.base'.

Additionally, I am not sure about the deprecation test procedure exactly, should I move my deprecation tests to tests/deprecated_api? If so, I am assuming it's moved to the 1.8 files, is that correct?

[awaelchli]

Great work!

I was wondering if we should also implement wrappers for other functionality in current loggers/base.py for backward compatibility? Such as DummyLogger, or LoggerCollection.

Yes exactly, we should. The exception is LoggerCollection where you would need to just keep the existing deprecation message (because it gets removed in 1.8).

Additionally, I am not sure about the deprecation test procedure exactly, should I move my deprecation tests to tests/deprecated_api? If so, I am assuming it's moved to the 1.8 files, is that correct?

Yes, see my latest commit and the addition in test_remove_1-9.py. The same would be done for the other classes that had to move.

[akihironitta]

Thank you for your contribution!