logging-objects-with-schema 1.0.0__tar.gz → 1.0.2__tar.gz

{logging_objects_with_schema-1.0.0 → logging_objects_with_schema-1.0.2}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.4
 Name: logging-objects-with-schema
-Version: 1.0.0
-Summary: Proxy logging wrapper that validates extra fields against a JSON schema.
+Version: 1.0.2
+Summary: Schema-aware Python logging with strict extra validation and schema-driven field projection.
 Keywords: logging,schema,validation,structured-logging,structured-logs
 Author: Dmitrii Safronov
 Author-email: Dmitrii Safronov <dhameoelin+logging-objects-with-schema@gmail.com>
@@ -23,11 +23,12 @@ Description-Content-Type: text/markdown
 
 # python-logging-objects-with-schema
 
-This library provides a logger subclass built on top of the standard `logging`
-module that strictly controls additional `extra` fields using a JSON schema.
-`SchemaLogger` is a drop-in replacement for `logging.Logger` that validates
-`extra` fields against a JSON schema file (`logging_objects_with_schema.json`)
-in your application root directory.
+`SchemaLogger` extends Python's standard `logging.Logger` with schema-driven
+validation and projection of `extra` fields. It preserves the standard logging
+API while invalid structured data is dropped and reported separately.
+
+The schema is defined in `logging_objects_with_schema.json`, located by
+searching upward from the current working directory to the filesystem root.
 
 ## Schema as a contract
 
@@ -55,8 +56,9 @@ systems) can rely on a consistent log structure.
   where `int` is declared, and `int` is **not** accepted where `float` is
   declared. There are no implicit type conversions.
 - All validation problems are aggregated and logged as a single ERROR message
-  **after** the log record has been emitted, ensuring 100% compatibility with
-  standard logger behavior (no exceptions are raised).
+  **after** the log record has been emitted. Data-validation failures do not
+  raise from the logging call; valid fields are emitted and violations are
+  reported separately.
 - Application code must only send `extra` fields that are described in the
   schema and match the declared Python types. Any deviation from the schema
   is considered a contract violation.
@@ -71,7 +73,8 @@ pip install logging-objects-with-schema
 
 ### Quickstart (complete working example)
 
-First, create a schema file `logging_objects_with_schema.json` in your application root:
+First, create a schema file `logging_objects_with_schema.json` in the current
+working directory (or any parent directory up to the filesystem root):
 
 ```json
 {
@@ -149,7 +152,7 @@ logger.info(
 ```python
 from logging_objects_with_schema import SchemaLogger
 
-# SchemaLogger is a drop-in replacement - no exception handling needed.
+# SchemaLogger uses the standard logging API; data-validation failures do not raise.
 # If the schema has problems, the application will be terminated after
 # logging schema problems to stderr.
 logging.setLoggerClass(SchemaLogger)
@@ -164,9 +167,12 @@ logger.info("processing", extra={"user_id": "not-an-int"})  # Wrong type
 
 ## Schema location and format
 
-The schema file `logging_objects_with_schema.json` must be located in your
-application root directory. The library searches upward from the current working
-directory until it finds the file or reaches the filesystem root.
+The schema file `logging_objects_with_schema.json` is located by searching from
+the current working directory upward to the filesystem root. The first file
+found wins; the location of the script or package does not matter. A file in a
+parent directory is used without warning, so run the application with a fixed
+working directory (for example, `WORKDIR` in a container or `WorkingDirectory`
+in systemd).
 
 **Important**: If there are any problems with the schema (missing file, broken
 JSON, invalid structure, etc.), the application is terminated after logging
@@ -366,7 +372,7 @@ All keys are merged together - they are not replaced, only supplemented.
 - Each subclass must implement the logic to pass `forbidden_keys` to its parent
   if it wants to propagate keys from its own subclasses
 - The `forbidden_keys` parameter is optional - if not provided, only builtin
-  keys are used, maintaining 100% backward compatibility
+  keys are used, preserving the default forbidden-key behavior
 - `None` and empty `set()` are semantically equivalent for `forbidden_keys` -
   both mean "no additional forbidden keys" and produce the same result
 

{logging_objects_with_schema-1.0.0 → logging_objects_with_schema-1.0.2}/README.md

@@ -1,10 +1,11 @@
 # python-logging-objects-with-schema
 
-This library provides a logger subclass built on top of the standard `logging`
-module that strictly controls additional `extra` fields using a JSON schema.
-`SchemaLogger` is a drop-in replacement for `logging.Logger` that validates
-`extra` fields against a JSON schema file (`logging_objects_with_schema.json`)
-in your application root directory.
+`SchemaLogger` extends Python's standard `logging.Logger` with schema-driven
+validation and projection of `extra` fields. It preserves the standard logging
+API while invalid structured data is dropped and reported separately.
+
+The schema is defined in `logging_objects_with_schema.json`, located by
+searching upward from the current working directory to the filesystem root.
 
 ## Schema as a contract
 
@@ -32,8 +33,9 @@ systems) can rely on a consistent log structure.
   where `int` is declared, and `int` is **not** accepted where `float` is
   declared. There are no implicit type conversions.
 - All validation problems are aggregated and logged as a single ERROR message
-  **after** the log record has been emitted, ensuring 100% compatibility with
-  standard logger behavior (no exceptions are raised).
+  **after** the log record has been emitted. Data-validation failures do not
+  raise from the logging call; valid fields are emitted and violations are
+  reported separately.
 - Application code must only send `extra` fields that are described in the
   schema and match the declared Python types. Any deviation from the schema
   is considered a contract violation.
@@ -48,7 +50,8 @@ pip install logging-objects-with-schema
 
 ### Quickstart (complete working example)
 
-First, create a schema file `logging_objects_with_schema.json` in your application root:
+First, create a schema file `logging_objects_with_schema.json` in the current
+working directory (or any parent directory up to the filesystem root):
 
 ```json
 {
@@ -126,7 +129,7 @@ logger.info(
 ```python
 from logging_objects_with_schema import SchemaLogger
 
-# SchemaLogger is a drop-in replacement - no exception handling needed.
+# SchemaLogger uses the standard logging API; data-validation failures do not raise.
 # If the schema has problems, the application will be terminated after
 # logging schema problems to stderr.
 logging.setLoggerClass(SchemaLogger)
@@ -141,9 +144,12 @@ logger.info("processing", extra={"user_id": "not-an-int"})  # Wrong type
 
 ## Schema location and format
 
-The schema file `logging_objects_with_schema.json` must be located in your
-application root directory. The library searches upward from the current working
-directory until it finds the file or reaches the filesystem root.
+The schema file `logging_objects_with_schema.json` is located by searching from
+the current working directory upward to the filesystem root. The first file
+found wins; the location of the script or package does not matter. A file in a
+parent directory is used without warning, so run the application with a fixed
+working directory (for example, `WORKDIR` in a container or `WorkingDirectory`
+in systemd).
 
 **Important**: If there are any problems with the schema (missing file, broken
 JSON, invalid structure, etc.), the application is terminated after logging
@@ -343,7 +349,7 @@ All keys are merged together - they are not replaced, only supplemented.
 - Each subclass must implement the logic to pass `forbidden_keys` to its parent
   if it wants to propagate keys from its own subclasses
 - The `forbidden_keys` parameter is optional - if not provided, only builtin
-  keys are used, maintaining 100% backward compatibility
+  keys are used, preserving the default forbidden-key behavior
 - `None` and empty `set()` are semantically equivalent for `forbidden_keys` -
   both mean "no additional forbidden keys" and produce the same result
 

logging_objects_with_schema-1.0.2/pyproject.toml

@@ -0,0 +1,97 @@
+[build-system]
+requires = ["uv_build>=0.9.11,<0.14.0"]
+build-backend = "uv_build"
+
+[project]
+name = "logging-objects-with-schema"
+version = "1.0.2"
+description = "Schema-aware Python logging with strict extra validation and schema-driven field projection."
+readme = "README.md"
+requires-python = ">=3.11"
+dependencies = []
+license = "Apache-2.0"
+license-files = ["LICENSE"]
+keywords = [
+    "logging",
+    "schema",
+    "validation",
+    "structured-logging",
+    "structured-logs",
+]
+classifiers = [
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
+    "Programming Language :: Python :: 3.13",
+    "Programming Language :: Python :: 3.14",
+    "Programming Language :: Python :: 3 :: Only",
+    "Intended Audience :: Developers",
+    "Topic :: System :: Logging",
+    "Typing :: Typed",
+]
+
+[[project.authors]]
+name = "Dmitrii Safronov"
+email = "dhameoelin+logging-objects-with-schema@gmail.com"
+
+[project.urls]
+Source = "https://github.com/disafronov/python-logging-objects-with-schema"
+Issues = "https://github.com/disafronov/python-logging-objects-with-schema/issues"
+
+[dependency-groups]
+dev = [
+    "pytest>=7.0.0",
+    "pytest-cov>=4.0.0",
+    "black>=23.0.0",
+    "isort>=5.12.0",
+    "flake8>=6.0.0",
+    "flake8-pyproject>=1.2.3",
+    "mypy>=1.18.1",
+    "bandit>=1.8.6",
+    "pre-commit>=3.5.0",
+    "vulture>=2.0.0",
+]
+
+[tool.isort]
+profile = "black"
+
+[tool.black]
+line-length = 88
+include = '\.pyi?$'
+
+[tool.flake8]
+max-line-length = 88
+extend-ignore = [
+    "E203",
+    "W503",
+]
+exclude = [".venv"]
+
+[tool.mypy]
+files = ["src"]
+strict = true
+warn_unused_configs = true
+warn_unreachable = true
+
+[tool.coverage.run]
+source = ["src"]
+branch = true
+
+[tool.coverage.report]
+fail_under = 100
+exclude_lines = [
+    "raise AssertionError",
+    "raise NotImplementedError",
+    "if __name__ == .__main__.:",
+    '@(abc\.)?abstractmethod',
+]
+show_missing = true
+skip_covered = false
+
+[tool.coverage.html]
+directory = "htmlcov"
+
+[tool.vulture]
+min_confidence = 80
+ignore_names = ["cls"]
+paths = ["src"]

logging_objects_with_schema-1.0.0/pyproject.toml → logging_objects_with_schema-1.0.2/pyproject.toml.orig

@@ -1,11 +1,11 @@
 [build-system]
-requires = [ "uv_build >= 0.9.11, <0.10.0" ]
+requires = [ "uv_build>=0.9.11,<0.14.0" ]
 build-backend = "uv_build"
 
 [project]
 name = "logging-objects-with-schema"
-version = "1.0.0"
-description = "Proxy logging wrapper that validates extra fields against a JSON schema."
+version = "1.0.2"
+description = "Schema-aware Python logging with strict extra validation and schema-driven field projection."
 readme = "README.md"
 requires-python = ">=3.11"
 dependencies = [ ]
@@ -54,47 +54,21 @@ dev = [
 
 [tool.isort]
 profile = "black"
-line_length = 88
-multi_line_output = 3
 
 [tool.black]
 line-length = 88
 include = "\\.pyi?$"
-extend-exclude = """
-/(
-  \\.eggs
-  | \\.git
-  | \\.hg
-  | \\.mypy_cache
-  | \\.tox
-  | \\.venv
-  | build
-  | dist
-)/
-"""
 
 [tool.flake8]
 max-line-length = 88
 extend-ignore = [ "E203", "W503" ]
-exclude = [ ".venv", "__pycache__", ".git", "htmlcov" ]
+exclude = [ ".venv" ]
 
 [tool.mypy]
-exclude = "tests/"
-warn_return_any = true
+files = [ "src" ]
+strict = true
 warn_unused_configs = true
-disallow_untyped_defs = true
-disallow_incomplete_defs = true
-check_untyped_defs = true
-disallow_untyped_decorators = true
-no_implicit_optional = true
-warn_redundant_casts = true
-warn_unused_ignores = true
-warn_no_return = true
 warn_unreachable = true
-strict_equality = true
-
-[tool.bandit]
-exclude_dirs = [ ".venv", "__pycache__", ".git", "htmlcov", "tests" ]
 
 [tool.coverage.run]
 source = [ "src" ]
@@ -103,11 +77,8 @@ branch = true
 [tool.coverage.report]
 fail_under = 100
 exclude_lines = [
-  "def __repr__",
-  "if self\\.debug",
   "raise AssertionError",
   "raise NotImplementedError",
-  "if 0:",
   "if __name__ == .__main__.:",
   "@(abc\\.)?abstractmethod"
 ]
@@ -119,6 +90,5 @@ directory = "htmlcov"
 
 [tool.vulture]
 min_confidence = 80
-exclude = [ "__pycache__" ]
 ignore_names = [ "cls" ]
-paths = [ "src", "tests" ]
+paths = [ "src" ]

{logging_objects_with_schema-1.0.0 → logging_objects_with_schema-1.0.2}/src/logging_objects_with_schema/schema_loader.py

@@ -1,9 +1,10 @@
 """Schema loading and validation for logging_objects_with_schema.
 
 The schema is expected to live in a JSON file named
-``logging_objects_with_schema.json`` in the application root
-directory. The schema defines which extra fields are allowed to be
-emitted and which Python types they must have.
+``logging_objects_with_schema.json`` in the current working directory or one
+of its parent directories, up to the filesystem root; the first file found is
+used. The schema defines which extra fields are allowed to be emitted and which
+Python types they must have.
 """
 
 import functools
@@ -313,7 +314,7 @@ def _get_schema_path() -> Path:
 
 
 def _load_raw_schema(schema_path: Path) -> tuple[dict[str, Any], Path]:
-    """Load raw JSON schema from the application root.
+    """Load raw JSON schema from the resolved schema file.
 
     This function attempts to read and parse the schema file. If any problems
     occur (file not found, I/O errors, invalid JSON, wrong top-level type),

{logging_objects_with_schema-1.0.0 → logging_objects_with_schema-1.0.2}/src/logging_objects_with_schema/schema_logger.py

@@ -3,8 +3,8 @@
 This class extends the standard ``logging.Logger`` to validate and filter
 user-provided ``extra`` fields according to a compiled JSON schema. When
 validation problems are detected, they are logged as ERROR messages *after*
-the log record has been emitted, ensuring 100% compatibility with standard
-logger behavior.
+the main log record has been emitted. The standard logging call API is
+preserved, but ``extra`` handling intentionally differs from ``logging.Logger``.
 """
 
 import json
@@ -45,12 +45,14 @@ class SchemaLogger(logging.Logger):
 
     This class extends :class:`logging.Logger` to add validation for
     ``extra`` fields according to a compiled JSON schema. It is designed
-    to be used as a drop-in replacement via :func:`logging.setLoggerClass`.
+    to be installed via :func:`logging.setLoggerClass`. Logging calls retain
+    the standard API, while ``extra`` is schema-validated and projected.
 
-    The schema is loaded from ``logging_objects_with_schema.json`` in the
-    application root directory during initialization. If the schema cannot
-    be loaded or validated, the logger instance is not created, schema
-    problems are logged to stderr, and the application is terminated.
+    The schema is loaded from ``logging_objects_with_schema.json`` found by
+    searching upward from the current working directory to the filesystem root
+    during initialization. If the schema cannot be loaded or validated, the
+    logger instance is not created, schema problems are logged to stderr, and
+    the application is terminated.
 
     Example:
         >>> import logging
@@ -117,8 +119,8 @@ class SchemaLogger(logging.Logger):
         This method validates and filters the ``extra`` parameter according
         to the compiled schema before delegating to the parent class. If
         validation problems are detected, they are logged as ERROR messages
-        after the main log record has been emitted, ensuring compatibility
-        with standard logger behavior (no exceptions are raised).
+        after the main log record has been emitted. Invalid runtime ``extra``
+        values are reported separately instead of raising validation errors.
 
         Args:
             level: Logging level.
@@ -185,7 +187,6 @@ class SchemaLogger(logging.Logger):
                 sinfo,  # sinfo - stack info from caller
             )
             try:
-                self.callHandlers(error_record)
+                self.handle(error_record)
             except Exception:
-                # If handler failed, log error to stderr (standard logging behavior)
                 sys.stderr.write(f"Error in logging handler: {error_record}\n")