opentelemetry-exporter-http-transport: enable entry-point loading of transport implementations

[herin049]

Description

These changes enables entry-point loading of HTTP transport implementations via the opentelemetry_http_transport entry-point. Furthermore, this PR adds an abstract classmethod create() to support instantiation of transport classes loaded via the entry-point loading mechanism introduced in this PR. The motivation for these changes is to provide a low friction strategy for users to provide their own transport implementations.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

uv run tox -e py314-test-opentelemetry-exporter-http-transport

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

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

[Copilot]

Pull request overview

This PR adds a mechanism for discovering HTTP transport implementations via the opentelemetry_http_transport entry-point group, and introduces a new BaseHTTPTransport.create() factory API with corresponding tests for the built-in requests and urllib3 transports.

Changes:

• Add _load_http_transport_class() that resolves transports by name, falling back to entry-point discovery for non-built-in transports.
• Introduce a BaseHTTPTransport.create() classmethod and implement it for RequestsHTTPTransport and Urllib3HTTPTransport.
• Register built-in transports as opentelemetry_http_transport entry points and expand test coverage around loading and factory behavior.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
uv.lock	Adds opentelemetry-api dependency metadata for the transport package in the lockfile.
exporter/opentelemetry-exporter-http-transport/pyproject.toml	Adds opentelemetry-api dependency and registers transport entry points.
exporter/opentelemetry-exporter-http-transport/src/opentelemetry/exporter/http/transport/init.py	Implements transport-class loading with built-in fast-path + entry-point fallback.
exporter/opentelemetry-exporter-http-transport/src/opentelemetry/exporter/http/transport/_base.py	Adds the new BaseHTTPTransport.create() API.
exporter/opentelemetry-exporter-http-transport/src/opentelemetry/exporter/http/transport/_requests.py	Implements RequestsHTTPTransport.create().
exporter/opentelemetry-exporter-http-transport/src/opentelemetry/exporter/http/transport/_urllib3.py	Implements Urllib3HTTPTransport.create().
exporter/opentelemetry-exporter-http-transport/tests/test_load_transport.py	Adds tests for built-in vs entry-point transport loading behavior.
exporter/opentelemetry-exporter-http-transport/tests/test_requests_transport.py	Adds tests validating RequestsHTTPTransport.create() behavior.
exporter/opentelemetry-exporter-http-transport/tests/test_urllib3_transport.py	Adds tests validating Urllib3HTTPTransport.create() behavior.
exporter/opentelemetry-exporter-http-transport/test-requirements.in	Ensures opentelemetry-api is installed for tests.
exporter/opentelemetry-exporter-http-transport/test-requirements.latest.txt	Reflects updated test dependency resolution including opentelemetry-api.
exporter/opentelemetry-exporter-http-transport/test-requirements.oldest.txt	Reflects updated lowest-version test dependency resolution including opentelemetry-api.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[xrmx]

@herin049 looks like the last paragraph of the PR description is missing some content

[MikeGoldsmith]

Overall looks good. I've left some suggestions / queries.

[MikeGoldsmith]

Do we need to register these all the time? Won't that cause them to always use their entrypoints?

[herin049]

Technically these aren't needed, but I've added them for consistency (easy to search for all transport implementations) and to provide an example for users to provide their own entry-points (we follow the same pattern in the SDK). We do the check for known entry-points before we attempt to load anything, so these are still optimized away.