In kurobako/solver/optuna.py, _optuna_logger is used for outputting optimization progress. However, although _optuna_logger is created with optuna.logging.getLogger(__name__), the __name__ does not belong in optuna, returning a separate logger from Optuna's logging system. Thus _optuna_logger's log level does not change by optuna.logging._configure_library_root_logger().
This results in invisible logs when the trials are pruned, because no handler is set for _optuna_logger's info level. When a trial succeeds, _study._log_completed_trial is called, which in turn calls logger created inside Optuna, thus the log is outputted. However, this is not a good design either, because _log_completed_trial is a private member and is subject to future change.
We suggest the following changes:
Propagate logs to the root logger, so that the library users can set the handlers themselves
Define a custom log format on successful trials and remove the dependency on _study._log_completed_trial
contramundum53
commented
2 years ago
In
kurobako/solver/optuna.py,_optuna_loggeris used for outputting optimization progress. However, although_optuna_loggeris created withoptuna.logging.getLogger(__name__), the__name__does not belong inoptuna, returning a separate logger from Optuna's logging system. Thus_optuna_logger's log level does not change byoptuna.logging._configure_library_root_logger().This results in invisible logs when the trials are pruned, because no handler is set for
_optuna_logger'sinfolevel. When a trial succeeds,_study._log_completed_trialis called, which in turn calls logger created inside Optuna, thus the log is outputted. However, this is not a good design either, because_log_completed_trialis a private member and is subject to future change.We suggest the following changes:
_study._log_completed_trial