structlog-config 0.8.0__tar.gz → 0.9.0__tar.gz

{structlog_config-0.8.0 → structlog_config-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: structlog-config
-Version: 0.8.0
+Version: 0.9.0
 Summary: A comprehensive structlog configuration with sensible defaults for development and production environments, featuring context management, exception formatting, and path prettification.
 Keywords: logging,structlog,json-logging,structured-logging
 Author: Michael Bianco
@@ -26,19 +26,16 @@ Here are the main goals:
 * High performance JSON logging in production
 * All loggers, even plugin or system loggers, should route through the same formatter
 * Structured logging everywhere
+* Pytest plugin to easily capture logs and dump to a directory on failure. This is really important for LLMs so they can
+  easily consume logs and context for each test and handle them sequentially.
 * Ability to easily set thread-local log context
 * Nice log formatters for stack traces, ORM ([ActiveModel/SQLModel](https://github.com/iloveitaly/activemodel)), etc
 * Ability to log level and output (i.e. file path) *by logger* for easy development debugging
 * If you are using fastapi, structured logging for access logs
+* [Improved exception logging with beautiful-traceback](https://github.com/iloveitaly/beautiful-traceback)
 
 ## Installation
 
-```bash
-pip install structlog-config
-```
-
-Or with [uv](https://docs.astral.sh/uv/):
-
 ```bash
 uv add structlog-config
 ```
@@ -51,9 +48,12 @@ from structlog_config import configure_logger
 log = configure_logger()
 
 log.info("the log", key="value")
+
+# named logger just like stdlib, but with a different syntax
+custom_named_logger = structlog.get_logger(logger_name="test")
 ```
 
-## JSON Logging for Production
+## JSON Logging in Production
 
 JSON logging is automatically enabled in production and staging environments (`PYTHON_ENV=production` or `PYTHON_ENV=staging`):
 
@@ -72,11 +72,13 @@ log = configure_logger(json_logger=True)
 log = configure_logger(json_logger=False)
 ```
 
-JSON logs use [orjson](https://github.com/ijl/orjson) for performance, include sorted keys and ISO timestamps, and serialize exceptions cleanly. Note that `PYTHON_LOG_PATH` is ignored with JSON logging (stdout only).
+JSON logs use [orjson](https://github.com/ijl/orjson) for performance, include sorted keys and ISO timestamps, and serialize exceptions cleanly.
+
+Note that `PYTHON_LOG_PATH` is ignored with JSON logging (stdout only).
 
 ## TRACE Logging Level
 
-This package adds support for a custom `TRACE` logging level (level 5) that's even more verbose than `DEBUG`. This is useful for extremely detailed debugging scenarios.
+This package adds support for a custom `TRACE` logging level (level 5) that's even more verbose than `DEBUG`.
 
 The `TRACE` level is automatically set up when you call `configure_logger()`. You can use it like any other logging level:
 
@@ -88,7 +90,7 @@ log = configure_logger()
 
 # Using structlog
 log.info("This is info")
-log.debug("This is debug") 
+log.debug("This is debug")
 log.trace("This is trace")  # Most verbose
 
 # Using stdlib logging
@@ -136,8 +138,6 @@ log.info("Processing file", file_path=Path.cwd() / "data" / "users.csv")
 
 ### Whenever Datetime Formatter
 
-**Note:** Requires `pip install whenever` to be installed.
-
 Formats [whenever](https://github.com/ariebovenberg/whenever) datetime objects without their class wrappers for cleaner output:
 
 ```python
@@ -152,8 +152,6 @@ Supports all whenever datetime types: `ZonedDateTime`, `Instant`, `LocalDateTime
 
 ### ActiveModel Object Formatter
 
-**Note:** Requires `pip install activemodel` and `pip install typeid-python` to be installed.
-
 Automatically converts [ActiveModel](https://github.com/iloveitaly/activemodel) BaseModel instances to their ID representation and TypeID objects to strings:
 
 ```python
@@ -166,8 +164,6 @@ log.info("User action", user=user)
 
 ### FastAPI Context
 
-**Note:** Requires `pip install starlette-context` to be installed.
-
 Automatically includes all context data from [starlette-context](https://github.com/tomwojcik/starlette-context) in your logs, useful for request tracing:
 
 ```python
@@ -193,63 +189,102 @@ Here's how to use it:
 1. [Disable fastapi's default logging.](https://github.com/iloveitaly/python-starter-template/blob/f54cb47d8d104987f2e4a668f9045a62e0d6818a/main.py#L55-L56)
 2. [Add the middleware to your FastAPI app.](https://github.com/iloveitaly/python-starter-template/blob/f54cb47d8d104987f2e4a668f9045a62e0d6818a/app/routes/middleware/__init__.py#L63-L65)
 
-## Pytest Plugin: Capture Logs on Failure
+## Pytest Plugin: Capture Output on Failure
 
-A pytest plugin that captures logs per-test and displays them only when tests fail. This keeps your test output clean while ensuring you have all the debugging information you need when something goes wrong.
+A pytest plugin that captures stdout, stderr, and exceptions from failing tests and writes them to organized output files. This is useful for debugging test failures, especially in CI/CD environments where you need to inspect output after the fact.
 
 ### Features
 
-- Only shows logs for failing tests (keeps output clean)
-- Captures logs from all test phases (setup, call, teardown)
-- Unique log file per test
-- Optional persistent log storage for debugging
-- Automatically handles `PYTHON_LOG_PATH` environment variable
+- Captures stdout, stderr, and exception tracebacks for failing tests
+- Only creates output for failing tests (keeps directories clean)
+- Separate files for each output type (stdout.txt, stderr.txt, exception.txt)
+- Captures all test phases (setup, call, teardown)
+- Optional fd-level capture for subprocess output
 
 ### Usage
 
-Enable the plugin with the `--capture-logs-on-fail` flag:
+Enable the plugin with the `--structlog-output` flag and `-s` (to disable pytest's built-in capture):
 
 ```bash
-pytest --capture-logs-on-fail
+pytest --structlog-output=./test-output -s
 ```
 
-Or enable it permanently in `pytest.ini` or `pyproject.toml`:
+The `--structlog-output` flag both enables the plugin and specifies where output files should be written.
+
+**Recommended:** Also disable pytest's logging plugin with `-p no:logging` to avoid duplicate/interfering capture:
 
-```toml
-[tool.pytest.ini_options]
-addopts = ["--capture-logs-on-fail"]
+```bash
+pytest --structlog-output=./test-output -s -p no:logging
 ```
 
-### Persist Logs to Directory
+While the plugin works without this flag, disabling pytest's logging capture ensures cleaner output and avoids any potential conflicts between the two capture mechanisms.
 
-To keep all test logs for later inspection (useful for CI/CD debugging):
+### Output Structure
 
-```bash
-pytest --capture-logs-dir=./test-logs
+Each failing test gets its own directory with separate files:
+
+```
+test-output/
+    test_module__test_name/
+        stdout.txt      # stdout from test (includes setup, call, and teardown phases)
+        stderr.txt      # stderr from test (includes setup, call, and teardown phases)
+        exception.txt   # exception traceback
+```
+
+### Advanced: fd-level Capture
+
+For tests that spawn subprocesses or write directly to file descriptors, you can enable fd-level capture. This is useful for integration tests that run external processes (such a server which replicates a production environment).
+
+#### Add fixture to function signature
+
+Great for a single single test:
+
+```python
+def test_with_subprocess(file_descriptor_output_capture):
+    # subprocess.run() output will be captured
+    subprocess.run(["echo", "hello from subprocess"])
+
+    # multiprocessing.Process output will be captured
+    from multiprocessing import Process
+    proc = Process(target=lambda: print("hello from process"))
+    proc.start()
+    proc.join()
+
+    assert False  # Trigger failure to write output files
 ```
 
-This creates a log file for each test and disables automatic cleanup.
+Alternatively, you can use `@pytest.mark.usefixtures("file_descriptor_output_capture")`
 
-### How It Works
 
-1. Sets `PYTHON_LOG_PATH` environment variable to a unique temp file for each test
-2. Your application logs (via `configure_logger()`) write to this file
-3. On test failure, the plugin prints the captured logs to stdout
-4. Log files are cleaned up after the test session (unless `--capture-logs-dir` is used)
+#### All tests in directory
 
-### Example Output
+Add to `conftest.py`:
 
-When a test fails, you'll see:
+```python
+import pytest
 
+pytestmark = pytest.mark.usefixtures("file_descriptor_output_capture")
 ```
-FAILED tests/test_user.py::test_user_login
 
---- Captured logs for failed test (call): tests/test_user.py::test_user_login ---
-2025-11-01 18:30:00 [info] User login started user_id=123
-2025-11-01 18:30:01 [error] Database connection failed timeout=5.0
+### Example
+
+When a test fails:
+
+```python
+def test_user_login():
+    print("Starting login process")
+    print("ERROR: Connection failed", file=sys.stderr)
+    assert False, "Login failed"
 ```
 
-For passing tests, no log output is shown, keeping your test output clean and focused.
+You'll get:
+
+```
+test-output/test_user__test_user_login/
+    stdout.txt: "Starting login process"
+    stderr.txt: "ERROR: Connection failed"
+    exception.txt: Full traceback with "AssertionError: Login failed"
+```
 
 ## Beautiful Traceback Support
 

{structlog_config-0.8.0 → structlog_config-0.9.0}/README.md

@@ -9,19 +9,16 @@ Here are the main goals:
 * High performance JSON logging in production
 * All loggers, even plugin or system loggers, should route through the same formatter
 * Structured logging everywhere
+* Pytest plugin to easily capture logs and dump to a directory on failure. This is really important for LLMs so they can
+  easily consume logs and context for each test and handle them sequentially.
 * Ability to easily set thread-local log context
 * Nice log formatters for stack traces, ORM ([ActiveModel/SQLModel](https://github.com/iloveitaly/activemodel)), etc
 * Ability to log level and output (i.e. file path) *by logger* for easy development debugging
 * If you are using fastapi, structured logging for access logs
+* [Improved exception logging with beautiful-traceback](https://github.com/iloveitaly/beautiful-traceback)
 
 ## Installation
 
-```bash
-pip install structlog-config
-```
-
-Or with [uv](https://docs.astral.sh/uv/):
-
 ```bash
 uv add structlog-config
 ```
@@ -34,9 +31,12 @@ from structlog_config import configure_logger
 log = configure_logger()
 
 log.info("the log", key="value")
+
+# named logger just like stdlib, but with a different syntax
+custom_named_logger = structlog.get_logger(logger_name="test")
 ```
 
-## JSON Logging for Production
+## JSON Logging in Production
 
 JSON logging is automatically enabled in production and staging environments (`PYTHON_ENV=production` or `PYTHON_ENV=staging`):
 
@@ -55,11 +55,13 @@ log = configure_logger(json_logger=True)
 log = configure_logger(json_logger=False)
 ```
 
-JSON logs use [orjson](https://github.com/ijl/orjson) for performance, include sorted keys and ISO timestamps, and serialize exceptions cleanly. Note that `PYTHON_LOG_PATH` is ignored with JSON logging (stdout only).
+JSON logs use [orjson](https://github.com/ijl/orjson) for performance, include sorted keys and ISO timestamps, and serialize exceptions cleanly.
+
+Note that `PYTHON_LOG_PATH` is ignored with JSON logging (stdout only).
 
 ## TRACE Logging Level
 
-This package adds support for a custom `TRACE` logging level (level 5) that's even more verbose than `DEBUG`. This is useful for extremely detailed debugging scenarios.
+This package adds support for a custom `TRACE` logging level (level 5) that's even more verbose than `DEBUG`.
 
 The `TRACE` level is automatically set up when you call `configure_logger()`. You can use it like any other logging level:
 
@@ -71,7 +73,7 @@ log = configure_logger()
 
 # Using structlog
 log.info("This is info")
-log.debug("This is debug") 
+log.debug("This is debug")
 log.trace("This is trace")  # Most verbose
 
 # Using stdlib logging
@@ -119,8 +121,6 @@ log.info("Processing file", file_path=Path.cwd() / "data" / "users.csv")
 
 ### Whenever Datetime Formatter
 
-**Note:** Requires `pip install whenever` to be installed.
-
 Formats [whenever](https://github.com/ariebovenberg/whenever) datetime objects without their class wrappers for cleaner output:
 
 ```python
@@ -135,8 +135,6 @@ Supports all whenever datetime types: `ZonedDateTime`, `Instant`, `LocalDateTime
 
 ### ActiveModel Object Formatter
 
-**Note:** Requires `pip install activemodel` and `pip install typeid-python` to be installed.
-
 Automatically converts [ActiveModel](https://github.com/iloveitaly/activemodel) BaseModel instances to their ID representation and TypeID objects to strings:
 
 ```python
@@ -149,8 +147,6 @@ log.info("User action", user=user)
 
 ### FastAPI Context
 
-**Note:** Requires `pip install starlette-context` to be installed.
-
 Automatically includes all context data from [starlette-context](https://github.com/tomwojcik/starlette-context) in your logs, useful for request tracing:
 
 ```python
@@ -176,63 +172,102 @@ Here's how to use it:
 1. [Disable fastapi's default logging.](https://github.com/iloveitaly/python-starter-template/blob/f54cb47d8d104987f2e4a668f9045a62e0d6818a/main.py#L55-L56)
 2. [Add the middleware to your FastAPI app.](https://github.com/iloveitaly/python-starter-template/blob/f54cb47d8d104987f2e4a668f9045a62e0d6818a/app/routes/middleware/__init__.py#L63-L65)
 
-## Pytest Plugin: Capture Logs on Failure
+## Pytest Plugin: Capture Output on Failure
 
-A pytest plugin that captures logs per-test and displays them only when tests fail. This keeps your test output clean while ensuring you have all the debugging information you need when something goes wrong.
+A pytest plugin that captures stdout, stderr, and exceptions from failing tests and writes them to organized output files. This is useful for debugging test failures, especially in CI/CD environments where you need to inspect output after the fact.
 
 ### Features
 
-- Only shows logs for failing tests (keeps output clean)
-- Captures logs from all test phases (setup, call, teardown)
-- Unique log file per test
-- Optional persistent log storage for debugging
-- Automatically handles `PYTHON_LOG_PATH` environment variable
+- Captures stdout, stderr, and exception tracebacks for failing tests
+- Only creates output for failing tests (keeps directories clean)
+- Separate files for each output type (stdout.txt, stderr.txt, exception.txt)
+- Captures all test phases (setup, call, teardown)
+- Optional fd-level capture for subprocess output
 
 ### Usage
 
-Enable the plugin with the `--capture-logs-on-fail` flag:
+Enable the plugin with the `--structlog-output` flag and `-s` (to disable pytest's built-in capture):
 
 ```bash
-pytest --capture-logs-on-fail
+pytest --structlog-output=./test-output -s
 ```
 
-Or enable it permanently in `pytest.ini` or `pyproject.toml`:
+The `--structlog-output` flag both enables the plugin and specifies where output files should be written.
+
+**Recommended:** Also disable pytest's logging plugin with `-p no:logging` to avoid duplicate/interfering capture:
 
-```toml
-[tool.pytest.ini_options]
-addopts = ["--capture-logs-on-fail"]
+```bash
+pytest --structlog-output=./test-output -s -p no:logging
 ```
 
-### Persist Logs to Directory
+While the plugin works without this flag, disabling pytest's logging capture ensures cleaner output and avoids any potential conflicts between the two capture mechanisms.
 
-To keep all test logs for later inspection (useful for CI/CD debugging):
+### Output Structure
 
-```bash
-pytest --capture-logs-dir=./test-logs
+Each failing test gets its own directory with separate files:
+
+```
+test-output/
+    test_module__test_name/
+        stdout.txt      # stdout from test (includes setup, call, and teardown phases)
+        stderr.txt      # stderr from test (includes setup, call, and teardown phases)
+        exception.txt   # exception traceback
+```
+
+### Advanced: fd-level Capture
+
+For tests that spawn subprocesses or write directly to file descriptors, you can enable fd-level capture. This is useful for integration tests that run external processes (such a server which replicates a production environment).
+
+#### Add fixture to function signature
+
+Great for a single single test:
+
+```python
+def test_with_subprocess(file_descriptor_output_capture):
+    # subprocess.run() output will be captured
+    subprocess.run(["echo", "hello from subprocess"])
+
+    # multiprocessing.Process output will be captured
+    from multiprocessing import Process
+    proc = Process(target=lambda: print("hello from process"))
+    proc.start()
+    proc.join()
+
+    assert False  # Trigger failure to write output files
 ```
 
-This creates a log file for each test and disables automatic cleanup.
+Alternatively, you can use `@pytest.mark.usefixtures("file_descriptor_output_capture")`
 
-### How It Works
 
-1. Sets `PYTHON_LOG_PATH` environment variable to a unique temp file for each test
-2. Your application logs (via `configure_logger()`) write to this file
-3. On test failure, the plugin prints the captured logs to stdout
-4. Log files are cleaned up after the test session (unless `--capture-logs-dir` is used)
+#### All tests in directory
 
-### Example Output
+Add to `conftest.py`:
 
-When a test fails, you'll see:
+```python
+import pytest
 
+pytestmark = pytest.mark.usefixtures("file_descriptor_output_capture")
 ```
-FAILED tests/test_user.py::test_user_login
 
---- Captured logs for failed test (call): tests/test_user.py::test_user_login ---
-2025-11-01 18:30:00 [info] User login started user_id=123
-2025-11-01 18:30:01 [error] Database connection failed timeout=5.0
+### Example
+
+When a test fails:
+
+```python
+def test_user_login():
+    print("Starting login process")
+    print("ERROR: Connection failed", file=sys.stderr)
+    assert False, "Login failed"
 ```
 
-For passing tests, no log output is shown, keeping your test output clean and focused.
+You'll get:
+
+```
+test-output/test_user__test_user_login/
+    stdout.txt: "Starting login process"
+    stderr.txt: "ERROR: Connection failed"
+    exception.txt: Full traceback with "AssertionError: Login failed"
+```
 
 ## Beautiful Traceback Support
 

{structlog_config-0.8.0 → structlog_config-0.9.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "structlog-config"
-version = "0.8.0"
+version = "0.9.0"
 description = "A comprehensive structlog configuration with sensible defaults for development and production environments, featuring context management, exception formatting, and path prettification."
 keywords = ["logging", "structlog", "json-logging", "structured-logging"]
 readme = "README.md"
@@ -17,8 +17,11 @@ authors = [{ name = "Michael Bianco", email = "mike@mikebian.co" }]
 [project.optional-dependencies]
 fastapi = ["fastapi-ipware>=0.1.0"]
 
+[project.entry-points.pytest11]
+structlog_config = "structlog_config.pytest_plugin"
+
 [build-system]
-requires = ["uv_build>=0.8.11,<0.9.0"]
+requires = ["uv_build>=0.9.0,<0.10.0"]
 build-backend = "uv_build"
 
 [tool.uv.build-backend]
@@ -37,7 +40,7 @@ dev = [
 ]
 
 [tool.pyright]
-exclude = ["playground/", "tmp/", ".venv/", "tests/"]
+exclude = ["examples/", "playground/", "tmp/", ".venv/", "tests/"]
 
 [tool.ruff]
 extend-exclude = ["playground.py", "playground/"]

{structlog_config-0.8.0 → structlog_config-0.9.0}/structlog_config/__init__.py

@@ -1,5 +1,5 @@
 from contextlib import _GeneratorContextManager
-from typing import Generator, Protocol
+from typing import Protocol
 
 import orjson
 import structlog
@@ -20,11 +20,12 @@ from structlog_config.formatters import (
 
 from . import (
     packages,
-    trace,  # noqa: F401
+    trace,  # noqa: F401 (import has side effects for trace level setup)
 )
 from .constants import NO_COLOR, package_logger
-from .environments import is_production, is_pytest, is_staging
+from .environments import is_pytest
 from .levels import get_environment_log_level_as_string
+from .hook import install_exception_hook
 from .stdlib_logging import (
     redirect_stdlib_loggers,
 )
@@ -146,6 +147,10 @@ class LoggerWithContext(FilteringBoundLogger, Protocol):
         "clear thread-local context"
         ...
 
+    def trace(self, *args, **kwargs) -> None:  # noqa: F811
+        "trace level logging"
+        ...
+
 
 # TODO this may be a bad idea, but I really don't like how the `bound` stuff looks and how to access it, way too ugly
 def add_simple_context_aliases(log) -> LoggerWithContext:
@@ -157,7 +162,10 @@ def add_simple_context_aliases(log) -> LoggerWithContext:
 
 
 def configure_logger(
-    *, logger_factory=None, json_logger: bool | None = None
+    *,
+    json_logger: bool = False,
+    logger_factory=None,
+    install_exception_hook: bool = False,
 ) -> LoggerWithContext:
     """
     Create a struct logger with some special additions:
@@ -170,9 +178,10 @@ def configure_logger(
     >>> log.clear()
 
     Args:
+        json_logger: Flag to use JSON logging. Defaults to False.
         logger_factory: Optional logger factory to override the default
-        json_logger: Optional flag to use JSON logging. If None, defaults to
-            production or staging environment sourced from PYTHON_ENV.
+        install_exception_hook: Optional flag to install a global exception hook
+            that logs uncaught exceptions using structlog. Defaults to False.
     """
     setup_trace()
 
@@ -180,8 +189,10 @@ def configure_logger(
     # This is important for tests where configure_logger might be called multiple times
     structlog.reset_defaults()
 
-    if json_logger is None:
-        json_logger = is_production() or is_staging()
+    if install_exception_hook:
+        from .hook import install_exception_hook as _install_hook
+
+        _install_hook(json_logger)
 
     redirect_stdlib_loggers(json_logger)
     redirect_showwarnings()

structlog_config-0.9.0/structlog_config/environments.py

@@ -0,0 +1,8 @@
+import os
+
+
+def is_pytest():
+    """
+    PYTEST_CURRENT_TEST is set by pytest to indicate the current test being run
+    """
+    return "PYTEST_CURRENT_TEST" in os.environ

{structlog_config-0.8.0 → structlog_config-0.9.0}/structlog_config/fastapi_access_logger.py

@@ -61,7 +61,7 @@ def client_ip_from_request(request: Request | WebSocket) -> str | None:
     Uses fastapi-ipware library to properly extract client IP from various proxy headers.
     Fallback to direct client connection if no proxy headers found.
     """
-    ip, trusted_route = ipware.get_client_ip_from_request(request)
+    ip, trusted_route = ipware.get_client_ip_from_request(request)  # type: ignore
     if ip:
         log.debug(
             "extracted client IP from headers", ip=ip, trusted_route=trusted_route

{structlog_config-0.8.0 → structlog_config-0.9.0}/structlog_config/formatters.py

@@ -21,9 +21,9 @@ def simplify_activemodel_objects(
     What's tricky about this method, and other structlog processors, is they are run *after* a response
     is returned to the user. So, they don't error out in tests and it doesn't impact users. They do show up in Sentry.
     """
-    from activemodel import BaseModel
-    from sqlalchemy.orm.base import object_state
-    from typeid import TypeID
+    from activemodel import BaseModel  # type: ignore
+    from sqlalchemy.orm.base import object_state  # type: ignore
+    from typeid import TypeID  # type: ignore
 
     for key, value in list(event_dict.items()):
         if isinstance(value, BaseModel):
@@ -181,7 +181,7 @@ def add_fastapi_context(
 
     https://github.com/tomwojcik/starlette-context/blob/master/example/setup_logging.py
     """
-    from starlette_context import context
+    from starlette_context import context  # type: ignore
 
     if context.exists():
         event_dict.update(context.data)

structlog_config-0.9.0/structlog_config/hook.py

@@ -0,0 +1,20 @@
+import sys
+
+import structlog
+
+
+def install_exception_hook(json_logger: bool = False):
+    def structlog_excepthook(exc_type, exc_value, exc_traceback):
+        if issubclass(exc_type, KeyboardInterrupt):
+            sys.__excepthook__(exc_type, exc_value, exc_traceback)
+            return
+
+        logger = structlog.get_logger()
+
+        # We rely on structlog's configuration (configured in __init__.py) 
+        # to handle the exception formatting based on whether it's JSON or Console mode.
+        logger.exception(
+            "uncaught_exception", exc_info=(exc_type, exc_value, exc_traceback)
+        )
+
+    sys.excepthook = structlog_excepthook

{structlog_config-0.8.0 → structlog_config-0.9.0}/structlog_config/packages.py

@@ -3,36 +3,36 @@ Determine if certain packages are installed to conditionally enable processors
 """
 
 try:
-    import orjson
+    import orjson  # type: ignore
 except ImportError:
     orjson = None
 
 try:
-    import sqlalchemy
+    import sqlalchemy  # type: ignore
 except ImportError:
     sqlalchemy = None
 
 try:
-    import activemodel
+    import activemodel  # type: ignore
 except ImportError:
     activemodel = None
 
 try:
-    import typeid
+    import typeid  # type: ignore
 except ImportError:
     typeid = None
 
 try:
-    import beautiful_traceback
+    import beautiful_traceback  # type: ignore
 except ImportError:
     beautiful_traceback = None
 
 try:
-    import starlette_context
+    import starlette_context  # type: ignore
 except ImportError:
     starlette_context = None
 
 try:
-    import whenever
+    import whenever  # type: ignore
 except ImportError:
     whenever = None