The litestar floor installs but cannot be imported

[lesnik512]

The litestar extra declares litestar>=2.19, which installs cleanly and then fails when the suite imports it:

ImportError: cannot import name 'FromPath' from 'litestar.params'

FromPath arrived in a later Litestar release than 2.19, so the declared floor names a version this package cannot use.

Worth noting this is invisible to an install-only check: everything installs and only fails once something imports it.

Reproduce

uv venv --python 3.10 .venv-lowest
VIRTUAL_ENV=.venv-lowest uv pip install --resolution lowest-direct ".[litestar]"
VIRTUAL_ENV=.venv-lowest uv pip install pytest pytest-asyncio pytest-cov
VIRTUAL_ENV=.venv-lowest python -m pytest -q

Fix

Raise the floor to the Litestar release that introduced FromPath, verified by running the suite at exactly that version.

---

Found by a lower-bound audit across the org, prompted by modern-python/.github#107. That issue proposes a CI job that would catch this class of defect standing; right now every gate resolves highest, so no floor is ever exercised.

13 of 23 repos audited had at least one broken floor. faststream-outbox had six and is now green at the lower bound on every supported interpreter.

[lesnik512]

Numbers from re-checking this at b336947, after #244 and #246 landed. Posting as data rather than to reopen — the scope call is yours, and #239 suggests it may already be deliberate.

The two defects this issue named are fixed. The declared floors as a whole are not yet green:

20 failed, 304 passed, 3 warnings

• 15 in tests/test_litestar_bootstrap.py — the app returns 500 where the test expects 200:

  assert '/gp-default/{user_id}' in '{"status_code":500,"detail":"Internal Server Error"}'
  

• 5 in tests/instruments/test_sentry_instrument.py:

  TypeError: LoggingIntegration.__init__() got an unexpected keyword argument 'sentry_logs_level'
  AttributeError: 'LoggingIntegration' object has no attribute '_sentry_logs_handler'
  

The sentry signature is the one #244 set out to fix. That fix guards on the sentry-sdk version, but sentry-sdk>=2.1 resolves to 2.1.0 at the bottom, and the guard does not hold there — so the floor still names a version the instrument cannot use.

Resolved floors in that run, for reference:

fastapi 0.133.0   faststream 0.6.0    litestar 2.19.0   opentelemetry-api 1.28.0
orjson 3.11.1     prometheus-client 0.20.0   sentry-sdk 2.1.0   structlog 23.2.0

Reproduce

EX=$(python -c "import tomllib;print(','.join(tomllib.load(open('pyproject.toml','rb'))['project']['optional-dependencies']))")
uv venv --python 3.10 .venv-lowest
VIRTUAL_ENV=.venv-lowest uv pip install --resolution lowest-direct ".[$EX]"
VIRTUAL_ENV=.venv-lowest uv pip install pytest pytest-cov pytest-asyncio httpx2 "redis>=5.2.1" "structlog>=22.2"
VIRTUAL_ENV=.venv-lowest python -m pytest -q

The second install is this repo's own dev group at default resolution, deliberately — flooring the test tooling as well produces failures that look like floor problems and are not. That is a real trap here: starlette 1.6 moved TestClient to httpx2, but an older resolved starlette calls httpx.Client(app=...), removed in httpx 0.28, and every test then fails with Client.__init__() got an unexpected keyword argument 'app'. It cost me a wrong bisect elsewhere before I spotted it.

Context

This came out of an org-wide lower-bound audit (modern-python/.github#107): 14 of 24 repos had at least one broken floor. The other 13 are now fixed and their issues closed.

lite-bootstrap was the one I did not attempt, because the failures cascade — a resolver stops at the first wall, so each fix only exposes the next. faststream-outbox took four rounds and three PRs (modern-python/faststream-outbox#185, modern-python/faststream-outbox#186, modern-python/faststream-outbox#187) to go green, and this repo has 28 extras rather than 5.

Worth saying plainly: keeping litestar>=2.19 and adapting the code, as #246 did, is the better strategy where it works — it preserves support breadth instead of cutting it, which every one of my 13 fixes did by raising floors. If the remaining 20 are worth chasing, that approach is likely to carry further than raising sentry-sdk would.