feat: add niquests instrumentation

[Ousret]

Description

Add OpenTelemetry instrumentation for the niquests (https://niquests.readthedocs.io/) HTTP client library. Niquests is a drop-in replacement for requests with native async support, HTTP/2, HTTP/3, and richer connection metadata. This instrumentation covers both the synchronous Session and the asynchronous AsyncSession interfaces.

Fixes # (issue)

• Close Add Opentelemetry Instrumentation jawah/niquests#354

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

I heavily inspired myself on other http client instrumentation to build up confidence that this one works too.

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Ousret / name: Ahmed (5324f3f)
• ✅ login: Ousret / name: Ahmed TAHRI (aaf5e70)

[herin049]

Hi @Ousret, generally speaking we prefer that library implementors consider adding first-class support for OTel over creating a dedicated instrumentation library. Have you reached out to the library authors to see if they would consider adding OTel instrumentation directly to niquests?

[Ousret]

I am the maintainer of Niquests. And I am willing to keep an eye into that contribution for the long run.
I really prefer that this contrib is hosted here as the other http client out there (aiohttp, requests, httpx, ..)

regards,

[Ousret]

I fixed the CI errors (misc).

Regards,

[MikeGoldsmith]

Thanks for the contribution @Ousret. We recently discussed this in the Python approvers/maintainers group and our guidance for cases like this is that library maintainers should add OpenTelemetry instrumentation directly into their library rather than adding an instrumentation package here. See our guidelines for native OpenTelemetry instrumentation.

Since you maintain niquests, you're in the best position to add native OTel support — it gives you tighter integration, avoids version coupling issues, and means instrumentation ships with the library itself. The OTel API is designed to be a lightweight dependency for exactly this use case.

We'd be happy to help if you have questions about integrating the OTel API into niquests directly. Closing this PR in favour of that approach.

[Ousret]

I was unaware of this context, and it seems I misinterpreted the native-instrumentation guidelines.

I understand the rationale, but I won't be pursuing native otel integration inside niquests itself. OpenTelemetry is one of several observability ecosystems users ask for, and taking on a first party dependency (plus the publishing, security, and long-term maintenance that comes with it) for each of them isn't sustainable across the OSS portfolio I already maintain. Keeping instrumentation as an opt-in, external adapter, exactly the model used today for requests, httpx, aiohttp, etc(...) is what allowed me to commit to maintaining this contrib long-term, as I offered earlier in the thread.

I'll leave the door open: if someone from the community wants to pick this up, either here or as an independent integration (3rd party package), I'm happy to review and support the effort.

Regards,

edit: It seems I didn't misinterpret the guidelines(...) Was updated after my PR via #4464 and applied retroactively.