Unable to install a library (pact-python) which depends on fastapi because of starlette version conflict

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

# requirements.txt

starlette==0.16.0

# This next one depends on fastapi
pact-python==1.4.0

Description

pip install -r requirements.txt

Operating System

macOS

Operating System Details

No response

FastAPI Version

0.67.0

Python Version

3.9

Additional Context

One fix I can think of is to make fastapi depend not on a fixed version of starlette starlette ==0.14.2" but on a range maybestarlette ~=0.14.2",. I wanted to open an issue first to discuss this as it has testing/release implications but I’m happy to investigate a PR if you think this is a good idea.

Was previously an issue with https://github.com/tiangolo/fastapi/issues/1407

[adriangb]

It might be beneficial for FastAPI to mark itself as “unstable” then and just accept (and integrate) any breaking changes coming from its dependencies. IMO everyone should have pinned dependencies in their deployables, so it shouldn’t be a problem for services/apps using FastAPI. It does generate more work for downstream libraries though.

A strong argument for this is: what happens if a critical vulnerability is found in Starlette right now? FastAPI is pinned to 0.14, but Starlette might release the fix in 0.16.2. Either FastAPI has to rush to bump the Starlette version, do a bunch of internal juggling to manage the breaking changes and release its own breaking change, or Starlette has to backport. This creates a situation where users have to introduce breaking changes just to get a security fix.

[meadsteve]

@tiangolo my situation was a little complicated. In this case the project I was working on used Starlette itself. But it also used pact which depended on fastapi with a conflicting Starlette. So we had to pin Starlette.

So I’m not really sure what the best thing to do here is. It’s mostly just python packaging can be complicated 😆