Repository: Lightning-AI/pytorch-lightning

Issue:
logging basic configuration level: INFO vs. WARNING (usability with W&B)
Thanks for the amazing package! I am having a great time using it.

# Issue 
Recently, I have been playing around with the weights and biases (W&B) logging functionality and I noticed that I was getting a lot of logging messages in my jupyter notebook while training my model (every epoch I got new messages).

When I looked into `logging.__init__.py`, the logging basic configuration was set with:

`logging.basicConfig(level=logging.INFO)`

However, that means a lot of INFO messages are being printed from W&B's use of the logger (e.g. when the RunManager modifies files).

# Potential Solution

To disable this, I switched the logging basic configuration in `logging.__init__.py` to:

`logging.basicConfig(level=logging.WARNING)`

Would this be a useful addition in general to the package or should I just keep this change local?


Discussion:
Honestly, best practice is for libraries not to configure logging at all. That way the user can set it up however they want. When libraries configure logging, you get weird things like this.

```python
logging.basicConfig(level=logging.DEBUG)
import pytorch_lightning.logging
# now log level is INFO :(
```

@williamFalcon thoughts on leaving logging configuration to the users?
the issue with logging is that it has to be sett by `logging.basicConfig` before fist usage, another option is to get the logger during a run and change the level... or we may think about using another logging package... let's have look at https://github.com/Delgan/loguru
@neggert i agree  that we should leave up to user but this is something people will have to remember... so maybe we set a default one if there's no config already set @Borda ?
I will need to check it...
Okay, spent a little bit of time thinking about this. I think it's fine to setup the lightning logger for the user, but we shouldn't be touching other loggers (e.g. WandB). To give a little more visibility to the user, what do we think about adding another arg to Trainer?

```
Arg:
    log_level (str, optional): Log level for the pytorch_lightning logger. Should be one of
    "DEBUG", "INFO", "WARNING", "ERROR", or `None`. If set to `None`, no logging
    configuration will be done; the user must configure logging if they want something
    other than Python defaults. Defaults to "INFO".
```

Then in the code, we do something like 

```python
if log_level is not None:
    logging.getLogger("pytorch_lighting").setLevel(log_level)
```

@Borda @williamFalcon Any thoughts? Only downside I see is yet another argument to `Trainer`.
I think the best practice is actually letting the package use dedicated logger, just as @neggert wrote: use `logging.getLogger("pytorch_lightning")`. Messing up with root logger has created much trouble in my case...
It's fine if default level of dedicated logger is set, since it won't change the level of other loggers, while users can still change the logger level if they want

And also the loggers under `/loggers` package should use subloggers (like `logging.getLogger('pytorch_lightning.neptune')` or maybe shorter like `logging.getLogger('lightning.neptune')`. Thus the log_level can be inherited.
yeah, having different logging level per logger sounds good... on the other hand, experiment-like logger does not save any logging messages aka terminal...
We can freely remove setting logging level from package init I guess. just trying to remember what was the reason we place it there...
I think that the case was that the logging was used somewhere in `lightning` package in plane code (not inside a function) and then touching this logging without proper setting `basicConfing` caused that no logging messages were shown...
> And also the loggers under `/loggers` package should use subloggers (like `logging.getLogger('pytorch_lightning.neptune')` or maybe shorter like `logging.getLogger('lightning.neptune')`. Thus the log_level can be inherited.

since #825 we support multiple loggers... The common practice is to have a `WARNING` level in a terminal and `DEBUG` in a file... What we could do is add a logger which would catch all logging messages like info/debug and write them to a special file... @cmpute  is it something you are interested in?

Resolving patch:
diff --git a/pytorch_lightning/__init__.py b/pytorch_lightning/__init__.py
--- a/pytorch_lightning/__init__.py
+++ b/pytorch_lightning/__init__.py
@@ -24,9 +24,6 @@
     # We are not importing the rest of the scikit during the build
     # process, as it may not be compiled yet
 else:
-    import logging as log
-    log.basicConfig(level=log.INFO)
-
     from .core import data_loader, LightningModule
     from .trainer import Trainer
     from .callbacks import Callback
diff --git a/pytorch_lightning/profiler/profiler.py b/pytorch_lightning/profiler/profiler.py
--- a/pytorch_lightning/profiler/profiler.py
+++ b/pytorch_lightning/profiler/profiler.py
@@ -6,9 +6,7 @@
 import pstats
 import io
 from abc import ABC, abstractmethod
-import logging
-
-logger = logging.getLogger(__name__)
+import logging as log
 
 
 class BaseProfiler(ABC):
@@ -124,7 +122,7 @@ def log_row(action, mean, total):
                 action, f"{np.mean(durations):.5}", f"{np.sum(durations):.5}",
             )
         output_string += "\n"
-        logger.info(output_string)
+        log.info(output_string)
 
 
 class AdvancedProfiler(BaseProfiler):
@@ -177,4 +175,4 @@ def describe(self):
             output_string = "\nProfiler Report\n"
             for action, stats in self.recorded_stats.items():
                 output_string += f"\nProfile stats for: {action}\n{stats}"
-            logger.info(output_string)
+            log.info(output_string)


Test patch: