search

open-telemetry / opentelemetry-python-contrib

OpenTelemetry instrumentation for Python modules
https://opentelemetry.io
Apache License 2.0
650 stars 536 forks source link

FastAPI/Starlette version spec out of alignment. #1420

Open whardier opened 1 year ago

whardier commented 1 year ago

Describe your environment Building a metapackage builder and noticed some potential issues with starlette instrumentation. Going to avoid providing starlette as part of our metapackager for now (and just assume fastapi instrumentation will be enough for our base)

Steps to reproduce Attempt to compile a requirements file listing the most recent fastapi and most recent instrumentation for both starlette and fastapi.

What is the expected behavior? Install both instrumentation for starlette and fastapi along with most recent starlette and fastapi supported by fastapi instrumentation.

What is the actual behavior? Starlette instrumentation restricted to 0.13.x while most recent fastapi requires a pinned version of starlette at 0.20.4

Could not find a version that matches starlette==0.20.4,~=0.13.0 (from opentelemetry-instrumentation-starlette[instruments]==0.34b0->-r constraints-all.in (line 84))
Tried: 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.1.16, 0.1.17, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.4.0, 0.4.1, 0.4.2, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8, 0.9.9, 0.9.10, 0.9.11, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4, 0.10.5, 0.10.6, 0.10.7, 0.11.0, 0.11.1, 0.11.2, 0.11.3, 0.11.4, 0.12.0, 0.12.1, 0.12.2, 0.12.3, 0.12.4, 0.12.5, 0.12.6, 0.12.7, 0.12.8, 0.12.9, 0.12.10, 0.12.11, 0.12.12, 0.12.13, 0.13.0, 0.13.1, 0.13.1, 0.13.2, 0.13.2, 0.13.3, 0.13.3, 0.13.4, 0.13.4, 0.13.5, 0.13.5, 0.13.6, 0.13.6, 0.13.7, 0.13.7, 0.13.8, 0.13.8, 0.14.0, 0.14.0, 0.14.1, 0.14.1, 0.14.2, 0.14.2, 0.15.0, 0.15.0, 0.16.0, 0.16.0, 0.17.0, 0.17.0, 0.17.1, 0.17.1, 0.18.0, 0.18.0, 0.19.0, 0.19.0, 0.19.1, 0.19.1, 0.20.0, 0.20.0, 0.20.1, 0.20.1, 0.20.2, 0.20.2, 0.20.3, 0.20.3, 0.20.4, 0.20.4, 0.21.0, 0.21.0
Skipped pre-versions: 0.12.0b1, 0.12.0b2, 0.12.0b3
There are incompatible versions in the resolved dependencies:
  starlette~=0.13.0 (from opentelemetry-instrumentation-starlette[instruments]==0.34b0->-r constraints-all.in (line 84))
  starlette==0.20.4 (from fastapi==0.85.1->opentelemetry-instrumentation-fastapi[instruments]==0.34b0->-r constraints-all.in (line 64))

Additional context Just noting this to see if this is an obvious oversight.

lzchen commented 1 year ago

@whardier I believe the instrumentations were created and supported versions were tested at the time independent of each other (it was an oversight that we didn't account for this specific use case).

@ocelotl @srikanthccv Curious do we want to handle this use case? Even if we do test and bump the latest supported version of starlette to ~= 0.20.4, there's nothing stopping fastapi to depend on later versions of starlette. Since starlette is still in alpha, I'm not sure about the implications of doing >= and having to solve breaking changes.

Might be another example of supporting incompatible versions (slightly related to: https://github.com/open-telemetry/opentelemetry-python-contrib/issues/1008) in which we handle case-by-case.

srikanthccv commented 1 year ago

I think we can pin the starlette to a version that works for both starlette and fastapi instrumentations.