Honor ORT_LOGGING_LEVEL environment variable on Python import#27645
Open
edenfunf wants to merge 1 commit intomicrosoft:mainfrom
Open
Honor ORT_LOGGING_LEVEL environment variable on Python import#27645edenfunf wants to merge 1 commit intomicrosoft:mainfrom
edenfunf wants to merge 1 commit intomicrosoft:mainfrom
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| import subprocess | ||
|
|
||
| for level in [0, 1, 2, 3, 4]: | ||
| result = subprocess.run( |
Check warning
Code scanning / lintrunner
RUFF/PLW1510
|
|
||
| def test_ort_logging_level_env_var(self): | ||
| # Verify that ORT_LOGGING_LEVEL is honored on import by running a subprocess. | ||
| import subprocess |
Check notice
Code scanning / lintrunner
RUFF/PLC0415
Contributor
There was a problem hiding this comment.
Pull request overview
Updates Python module initialization so ORT_LOGGING_LEVEL is applied before OrtEnv is created, making the configured logging severity effective from the first log message during import onnxruntime (and similarly for training). Also adds a small Python API surface + tests to validate the behavior.
Changes:
- Read and validate
ORT_LOGGING_LEVELduringCreateOrtEnv()in both inference and training Python modules. - Add
get_default_logger_severity()Python API and export it fromonnxruntime/__init__.py. - Add Python tests covering the new getter and env-var-on-import behavior via subprocess.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
onnxruntime/python/onnxruntime_pybind_module.cc |
Parse ORT_LOGGING_LEVEL before OrtEnv creation so import-time logs honor configured severity. |
orttraining/orttraining/python/orttraining_python_module.cc |
Apply the same import-time logging severity behavior for the training Python module. |
onnxruntime/python/onnxruntime_pybind_state.cc |
Expose get_default_logger_severity() via pybind. |
onnxruntime/__init__.py |
Re-export get_default_logger_severity from the Python top-level package. |
onnxruntime/test/python/onnxruntime_test_python.py |
Add tests for the new getter and for ORT_LOGGING_LEVEL behavior on import (subprocess-based). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
Comment on lines
+109
to
+113
| severity = onnxrt.get_default_logger_severity() | ||
| self.assertIsInstance(severity, int) | ||
| self.assertGreaterEqual(severity, 0) | ||
| self.assertLessEqual(severity, 4) | ||
|
|
The Python binding's CreateOrtEnv() function hardcoded ORT_LOGGING_LEVEL_WARNING as the initial logging severity, which meant the ORT_LOGGING_LEVEL environment variable had no effect on the messages emitted during module import. This change reads ORT_LOGGING_LEVEL (integer 0–4) before creating the OrtEnv instance so that the chosen severity is respected from the very first log message. The same fix is applied to the training binding (orttraining_python_module.cc), which contained an identical hardcoded value. A companion get_default_logger_severity() Python API is added alongside the existing set_default_logger_severity() so callers can inspect the active level, and two new unit tests verify both the API and the env-var behaviour. Fixes microsoft#27092
edenfunf
force-pushed
the
fix/honor-ort-logging-level-env-var
branch
from
104a143 to
f7f7782
Compare
edenfunf
added a commit
to edenfunf/onnxruntime
that referenced
this pull request
Mar 14, 2026
Add two unit tests that cover the ORT_LOGGING_LEVEL environment variable behaviour introduced in microsoft#27645: - test_get_default_logger_severity: verifies the new getter API returns a valid severity level - test_ort_logging_level_env_var: spawns a subprocess for each valid level (0-4) and confirms get_default_logger_severity() reflects the env var While adding the subprocess-based test, address two ruff findings: - PLC0415: move `import subprocess` to module-level instead of inside the test method body - PLW1510: pass explicit `check=False` to subprocess.run()
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
CreateOrtEnv()inonnxruntime/python/onnxruntime_pybind_module.ccnow reads theORT_LOGGING_LEVELenvironment variable before constructingOrtEnv, so the configured severity is active from the very first log message emitted duringimport onnxruntime.orttraining/orttraining/python/orttraining_python_module.cc.get_default_logger_severity()Python API is added (companion to the existingset_default_logger_severity()) and exported fromonnxruntime/__init__.py.onnxruntime_test_python.pycover the new API and the env-var behaviour.Why
ORT_LOGGING_LEVELis documented as a way to suppress noisy log output (e.g. GPU-discovery warnings in environments without a GPU), but it had no effect becauseCreateOrtEnv()hardcodedORT_LOGGING_LEVEL_WARNING. Users were forced to redirect stderr or callset_default_logger_severity()after import, by which point the spurious warnings had already been emitted.Fixes #27092
How
Env::Default().GetEnvironmentVar("ORT_LOGGING_LEVEL")is read at the start ofCreateOrtEnv(). If the value is a valid integer in[0, 4]it replaces the defaultORT_LOGGING_LEVEL_WARNING; any invalid or absent value leaves the existing default unchanged.Test plan
test_get_default_logger_severity– verifies the new getter returns a value in the valid range.test_ort_logging_level_env_var– spawns a subprocess for each valid severity level (0–4) withORT_LOGGING_LEVELset, then checks thatget_default_logger_severity()returns the expected value immediately after import.