configure_logging() called before DataDesigner() is silently overwritten

[andreatgretel]

Priority Level

Medium (Nice to have)

Is your feature request related to a problem? Please describe.

Calling configure_logging() before constructing a DataDesigner instance has no effect — the user's configuration is silently overwritten with defaults.

_initialize_interface_runtime() uses a module-level flag (_interface_runtime_initialized) to guard one-time setup, but configure_logging() itself never sets that flag. So when DataDesigner.__init__ triggers _initialize_interface_runtime(), it sees False and calls configure_logging() again with defaults.

MRE:

import logging
from data_designer.logging import LoggingConfig, configure_logging
from data_designer.interface.data_designer import DataDesigner

configure_logging(LoggingConfig.debug())
print(logging.getLogger("data_designer").level)  # 10 (DEBUG)

dd = DataDesigner(artifact_path="/tmp/dd_mre")
print(logging.getLogger("data_designer").level)  # 20 (INFO) — overwritten

Describe the solution you'd like

Track initialization state inside configure_logging() itself, so that _initialize_interface_runtime() can detect a prior user call and skip the default setup. For example, add a module-level _configured flag in logging.py that configure_logging() sets to True, and check it in _initialize_interface_runtime():

# logging.py
_configured = False

def configure_logging(config: LoggingConfig | None = None) -> None:
    global _configured
    _configured = True
    # ... rest unchanged

# data_designer.py
def _initialize_interface_runtime():
    global _interface_runtime_initialized
    if _interface_runtime_initialized:
        return
    from data_designer import logging as _logging_mod
    if not _logging_mod._configured:
        configure_logging()
    resolve_seed_default_model_settings()
    _interface_runtime_initialized = True

Note: importing the bool directly won't work (Python binds the value at import time). Use from data_designer import logging as _logging_mod and check _logging_mod._configured, or expose it via a function.

Describe alternatives you've considered

• Set _interface_runtime_initialized = True inside configure_logging(). Simpler but couples logging.py to the runtime init flag in data_designer.py.
• Check if the data_designer logger already has a non-default level before calling configure_logging() in _initialize_interface_runtime(). Avoids a new flag but is fragile — the logger could have been set by something else.

Additional context

We hit this in a downstream project that wraps DataDesigner and exposes configure_logging() as a user-facing API. The documented pattern (configure logging, then construct the interface) doesn't work due to this bug.

[andreatgretel]

Additional finding: configure_logging() also clobbers the root logger's handlers via root_logger.handlers.clear() on line 123 of logging.py. This means any application that has already configured stdlib logging (e.g. logging.basicConfig(...)) before importing or using DataDesigner will lose its handler setup.

MRE:

import logging

logging.basicConfig(format="APP: %(message)s", level=logging.INFO)
root = logging.getLogger()
print(root.handlers[0].formatter._fmt)  # APP: %(message)s

from data_designer.interface.data_designer import DataDesigner
print(root.handlers[0].formatter._fmt)  # [%(asctime)s] [%(levelname)s] %(message)s — clobbered

This happens because DD's _initialize_interface_runtime() is triggered during the import chain, which calls configure_logging() unconditionally.

A cleaner approach would be to attach the DD handler to the data_designer logger directly (with propagate = False) rather than clearing and rewriting the root logger. This way DD controls its own output without interfering with the host application's logging setup.