[Feature] openbb-cme: Add CME Group Equity Index Futures Provider (closes #7427)

[ray-singh]

Pull Request — OpenBB Platform

Description

• Added a new community provider openbb-cme for CME Group equity index futures settlement data, resolving [FR] Add CME Equity Index Futures Provider (ES, NQ, MNQ, MES) #7427.
• Data is sourced from the public CME settlements API (/CmeWS/mvc/Settlements/Futures/Settlements/{product_id}/FUT).
• Supported root symbols: ES, NQ, MES, MNQ, YM.

Fetchers added:

Fetcher	Standard model	Description
CMEFuturesHistoricalFetcher	FuturesHistorical	Daily OHLCV + settlement price + open interest per contract month
CMEFuturesCurveFetcher	FuturesCurve	Full futures term structure for a given date
CMEFuturesInfoFetcher	FuturesInfo	Contract specs (tick size, multiplier, point value) + latest front-month settlement
CMEFuturesInstrumentsFetcher	FuturesInstruments	Listed contracts with expiration dates

Dependencies:

• curl-cffi: required to impersonate Chrome120's TLS fingerprint and bypass Akamai Bot Manager on the CME API. Standard HTTP clients (httpx, aiohttp) receive 403 responses.

Platform changes:

• dev_install.py: added openbb-cme path entry for local development.
• pytest.ini: suppressed an unrelated pytest_ethereum plugin warning.

How has this been tested?

• 15 unit and cassette-based tests pass (pytest openbb_platform/providers/cme/tests/ -v).
• record_http tests replay pre-recorded JSON cassettes via a conftest.py fixture that patches _get_json. curl-cffi operates at the C level and cannot be intercepted by vcrpy, so cassettes are served this way instead.
• YAML stub cassettes created in tests/record/http/test_cme_fetchers/ to satisfy pytest_recorder's file-existence requirement.
• All 4 fetchers return valid data when called against the live CME API.
• black, ruff, pylint (10/10), and mypy pass with no errors.

Test configuration: Python 3.12, openbb-core installed from local path via dev_install.py.

• Ensure all unit and integration tests pass.
• Ensure the new provider and/or fetcher is stable and usable.
• New tests added for all 4 fetchers (unit + cassette replay).

Checklist

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas (curl-cffi TLS impersonation rationale documented in _get_json).
• My branch name follows GitFlow convention: feature/cme-provider.
• I am following the CONTRIBUTING guidelines.
• Tests follow the guidelines in CONTRIBUTING.md.

[CLAassistant]

All committers have signed the CLA.

[ray-singh]

Hello! Just wanted to follow up on this PR whenever you have a chance. I'm a first time contributor and I've signed the CLAd. If there are any changes you'd like to see, I'd be happy to make the updates. Thanks for your time!

[deeleeramone]

Hi @ray-singh, thanks for the PR. A couple of things here, a provider extension like this would need to expose the entire product suite across all asset classes, with programmatically generated metadata built from publicly available resources published by the exchange. Futures + options on futures, full contract specs.

New extension modules should be pointed towards the V5 branch- https://github.com/OpenBB-finance/OpenBB/tree/v5

[ray-singh]

Thanks for the feedback! That makes sense; I'll retarget the implementation to the V5 branch. Regarding scope, would you prefer an initial implementation that establishes the provider architecture and supports a subset of CME products (equity index futures) with the intention of expanding to the full product suite in follow-up PRs, or would you prefer the initial PR to include comprehensive coverage across all CME asset classes and options on futures? I'll align the implementation with whichever approach you think is a better fit.

[deeleeramone]

Regarding scope, @ray-singh, my preference is for the full implementation as one PR. The reason for this is that we generally consider the working branches to be production-ready, but unstable and subject to change. So, new items should be fully flushed out before merging.

For the extension itself, it would be a good idea to give it a router module as well so that all the endpoints would register regardless of openbb-derivatives being installed or not. You can look at the IMF/OECD providers for examples of this type of conditional pattern.

I know that CME has some new APIs behind a login, have you investigated what's available to individual, free, users from the access-controlled data? There was a lot of friction with the sign-up and dataset subscriptions, I believe they have simplified it all now and would be worth exploring.