Does FastAPI have to pin starlette?

[dimaqq]

First Check

• I added a very descriptive title to this issue.
• I used the GitHub search to find a similar issue and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from fastapi.testclient import TestClient

TestClient(app, headers={...})

Description

FastAPI re-exports starlette TestClient which seems to be an httpx.Client connected to the asgi app under test.

starlette has recently fixed the TestClient.__init__ to follow httpx.Client.__init__ so that the earlier accepts headers=... kwarg, just like the latter.

encode/starlette#1966

starlette has made a release 0.23.0, but the latest FastAPI pins a specific version starlette==0.22.0

Thus, as a dev, I can't use the latest "features" or more like reasonable expectations for the TestClient.

A newcomer would read the docs / source code and would expect TestClient to accept headers kwarg and get confused why that's rejected.

Thus, the question: is there a reason to pin a specific version of starlette?

Operating System

Other

Operating System Details

An issue with any OS.

FastAPI Version

0.88.0

Python Version

3.10, etc.

Additional Context

No response

[jgould22]

FastAPI is integrated quite closely with starlette, and unfortunately starlette doesn't use semantic versioning, so it's easy for a breaking starlette change to break FastAPI. The latest version of starlette does this, for example

#2532

If Starlette released a change that FastAPI did not support and you did not pin the version every install would break and cause everyone to have to pin starlette which is not desirable.

Generally in library(which fastapi is) code you should pin your dependencies, or use a lock file to ensure that the library is getting a version of its dependencies that it is known to support. For a library having known working code for a specific version is more important than features.

[dimaqq]

I guess as long as both FastAPI and Starlette are in the 0.x.x series, we just have to live with that.

P.S. I kinda wish that FastAPI at least would graduate, because SemVer has a gotcha for 0.x.x that most devs are not aware of. At least I was not and my peers were not.

[Kludex]

Conceptually, yes.

[caarmen]

Just ran into this.

• Upgraded httpx from 0.26.0 to 0.27.0. This adds a deprecation in TestClient. When running tests, we see:

  /path/to/lib/python3.12/site-packages/httpx/_client.py:680: DeprecationWarning: The 'app' shortcut is now deprecated. Use the explicit style 'transport=WSGITransport(app=...)' instead.
  

• Starlette 0.37.2 updates the way it creates TestClient to avoid the deprecation warning.
• Fastapi doesn't yet support Starlette 0.37.x.

Looks like the options are:

• accept the warning for now
• don't update httpx for now

[steve-mavens]

It could be worse: at some point httpx will remove that feature, and then your options will just be "don't update httpx for now" :-)

I think this is an unsolved problem in Python environment management, and different people have different answers to the question "does this need to be pinned". Hence for example https://iscinumpy.dev/post/bound-version-constraints/ , which lists many adverse consequences of pinning dependencies. In effect the answer it gives is "no, it does not need to be pinned. These consequences are unacceptable and when you don't pin your users can sort it out". But it relies for this conclusion heavily on the stated axiom "an under-constrained build is completely trivial to fix for any user". That does not at all match my personal experience of solving dependencies manually. pip-compile was not invented to perform a task that its users find completely trivial, let alone the even more sophisticated solvers. Specifically: applying the pin is completely trivial, but it's unboundedly difficult to debug an incompatibility to work out what pin you need for an indirect dependency you've never previously heard of.