Files
OpenBB/openbb_platform/core
dlee-bq 53d4dcc46d [Feature] Drop Python 3.10 and Resolve Open Dependabot Alerts (#7804)
* Drop Python 3.10 support

Python 3.10 reached end of life on 2026-10-01, and the patched releases of
Pillow (13.0.0) and filelock (>=4.2.1) require Python >=3.11, so the 3.10
resolution fork kept vulnerable versions in every lockfile.

- requires-python = ">=3.11,<4" in all pyproject.toml files, the
  cookiecutter template, and the CLI codegen project template
- CI: drop the ubuntu 3.10 matrix rows, move the macOS/Windows minimum
  rows and the lint jobs to 3.11, drop 3.10 from the nox sessions
- READMEs: state 3.11 as the minimum supported version

* Relock with patched certifi, filelock, virtualenv, Pillow, and fastmcp

Regenerate all 38 uv.lock files against requires-python >=3.11 and upgrade
only the packages with open Dependabot advisories:

- certifi 2026.7.22 -> 2026.10.23 (GHSA-6q48-6c7w-9gw2, compromised emSign CAs)
- virtualenv 21.14.7 -> 21.14.13
- filelock 4.1.0/4.2.0 -> 4.2.4
- Pillow 12.3.0 -> 13.0.0
- fastmcp / fastmcp-slim 4.1.0 -> 4.1.3

All other changes are removed Python 3.10-only resolution forks; no other
package changes version for Python 3.11+.

* desktop: bump zod, @hookform/resolvers, and vitest

- zod ^3.25.76 -> ^4.6.7 (GHSA-mrhx-c7xc-m3w5; no patched 3.x exists)
- @hookform/resolvers ^3.10.0 -> ^5.9.2 for zod 4 support
- vitest ^4.1.11 -> ^4.1.12 (@vitest/mocker GHSA-qxg6-89mg-rqv8,
  GHSA-xp26-3454-mjgp)
- override zod to the root version so @openbb/ui-pro, which declares
  zod ^3 but never imports it, does not pull in a second, vulnerable copy

* desktop: remove Python 3.10 from environment pickers

- version pickers in InstallComponents and AddExtensionSelector start at 3.11
- create_environment_from_requirements accepts 3.11 through 3.14 and falls
  back to 3.12 otherwise (previously 3.10 through 3.13)
- component tests select 3.11 instead of 3.10

* Remove Python 3.10 tomli fallbacks

With requires-python >=3.11, tomllib is always available, so the
version-conditional tomli imports are dead code.

- import tomllib directly in the cli and core config loaders, the
  mcp_server and platform_api config validators, dev_install.py, and
  the cli and cookiecutter tests; dev_install.py no longer pip-installs
  tomli on the fly
- drop the tomli>=2.0; python_version<'3.11' dependency from cli, core,
  mcp_server, and platform_api, plus platform_api's backport comment
- raise the fake-extension fixtures in cli/conftest.py,
  core/integration/conftest.py, and the charting test metadata to
  >=3.11
- relock cli, core, mcp_server, and platform_api; only the tomli
  requires-dist entry is removed and resolution markers are reordered,
  no package versions change

* Target Python 3.11 in ruff and ty for cli, core, mcp_server, platform_api, cookiecutter

With ruff target-version py310 and ty python-version 3.10, both tools
reject an unconditional `import tomllib`: ty reports it as unresolved
(exit 1) and ruff's isort classifies it as third-party. Raise the targets
in the projects that now import tomllib directly, and in the root
ruff.toml that governs dev_install.py.

- ruff target-version = "py311" and ty python-version = "3.11" in cli,
  core, mcp_server, platform_api, and cookiecutter; root ruff.toml
  target-version = "py311"
- UP042: OutputMode, ChartLifecycle, MCPType, and HTTPMethod become
  StrEnum; every consumer uses .value or == comparisons, so only str()
  and format() output change
- UP017: datetime.timezone.utc -> datetime.UTC (ruff autofix) in the cli
  dispatchers, the cli test generator, and a core test

* Fix ruff and ty failures in packages this PR touches

CI installs unpinned dependencies, so the lint jobs ran against
pandas 3.1.0, ruff 0.17.2, and ty 0.0.91.

- cli/conftest.py: guard the find_spec("openbb") lookup so ty no longer
  reports an Optional ModuleSpec/origin (failing Lint openbb-cli)
- quantitative: pandas 3.1 types Index.max() as object; cast max_date to
  Timestamp before period_start in attribution, factors, and
  risk_decomposition (failing ty)
- federal_reserve: use Series(...).dt.date instead of
  DatetimeIndex.date so neither pandas 3.0 nor 3.1 needs a ty: ignore
  (pandas 3.1 made the existing ignores unused, failing ty)
- core tests: type the filter_by_dates doubles as Data subclasses and
  cast the deliberate bad arguments in test_helpers.py; apply ruff format
  to test_docstring_generator_helpers.py
- platform_api README: apply ruff format to the Python code blocks

* Fix pandas 3.1 deprecations failing fred, sec, and eia tests

These suites turn warnings into errors, and pandas 3.1.0 adds
Pandas4Warning deprecations for several patterns they use. Every change
also passes with the locked pandas 3.0.6.

- fred, sec: replace inplace=True sort_values/reset_index/rename/
  set_index/drop with reassignment
- fred balance_of_payments, sec as_filed_widget: replace fillna with a
  string on float columns by astype(object).where(notna, ...)
- sec: build quarter start dates from ISO strings instead of parsing
  "2024Q2"-style strings; use the DataFrame constructor instead of
  DataFrame.from_records for column dicts; pad CIK lookup rows to two
  fields instead of constructing a ragged DataFrame
- eia: read EIA workbooks with the calamine engine (xlrd is deprecated);
  replace the xlrd dependency with python-calamine and relock; calamine
  workbooks are not safe for concurrent reads, so the petroleum status
  report serializes its sheet reads with a lock

* imf: fall back to the published catalog when the IMF API is unreachable

imf_cache.json.xz is generated at build time and is not committed, so
every CI build of openbb-imf needed a live api.imf.org. The only fallback
was actions/cache, and caches saved by pull_request runs are scoped to
that PR, so a new PR never had one. With api.imf.org returning
"503 no healthy upstream" during IMF's data portal maintenance window,
the build failed.

When live generation fails on a non-forced build, the hook now copies
imf_cache.json.xz from the latest openbb-imf wheel on PyPI, after
checking the wheel's sha256 against the digest PyPI publishes. Builds
with OPENBB_IMF_FORCE_CACHE_REBUILD=1, which the publish workflow sets,
still fail hard, so a release never ships a stale catalog.

---------

Co-authored-by: dlee-bq <325002271+dlee-bq@users.noreply.github.com>
2026-11-01 18:16:45 +00:00
..
2026-09-29 14:45:53 +00:00
2026-09-29 14:45:53 +00:00

openbb-core

openbb-core is the runtime that turns a collection of installed Python packages into the OpenBB Platform. By itself it ships no data, no providers, and no commands. Its job is to:

  1. Discover provider, command, and result-type extensions installed in the current Python environment via setuptools entry points.
  2. Stitch them together into a single typed Python client (from openbb import obb) and an equivalent FastAPI REST API.
  3. Execute calls against those extensions, normalise the output through shared Pydantic models, and return a uniform OBBject result wrapper.

If you are an end user, you install openbb (which depends on this package) and one or more provider extensions. If you are an extension author, you depend on openbb-core and register one of the entry points below.

Entry points

Extensions plug into the runtime through three setuptools entry-point groups defined in openbb_core/app/extension_loader.py. At import time, ExtensionLoader enumerates each group and the rest of the platform consumes the results.

openbb_core_extension

A Router to mount under the platform. Each entry point is loaded as an openbb_core.app.router.Router instance and merged into the root router. This is how command surfaces such as obb.equity, obb.economy, obb.derivatives get added.

# pyproject.toml of an extension
[project.entry-points."openbb_core_extension"]
equity = "openbb_equity.equity_router:router"

openbb_provider_extension

A Provider describing a data source — its credentials, the standard models it implements, and the Fetcher classes that satisfy them. Routers do not hard-code providers; they declare a standard model, and at call time the runtime picks a Fetcher from any installed provider that implements it.

[project.entry-points."openbb_provider_extension"]
yfinance = "openbb_yfinance:yfinance_provider"

openbb_obbject_extension

An Extension (see openbb_core/app/model/extension.py) attached to the OBBject result wrapper. There are two flavours, configured on the same Extension instance:

1. Accessor extensions (default — on_command_output=False)

Add a namespace attribute on every OBBject, pandas-style. The entry-point name becomes the attribute name. Used for opt-in transformations the caller explicitly invokes:

result = obb.equity.price.historical("AAPL")
result.charting.to_chart()  # accessor registered by openbb_charting
[project.entry-points."openbb_obbject_extension"]
charting = "openbb_charting:ext"   # ext = Extension(name="charting")

2. on_command_output callbacks (post-execution hooks)

Set on_command_output=True to make the extension run automatically on the OBBject returned by every command, or only by specific routes via command_output_paths. ExtensionLoader._register_command_output_callbacks indexes them by path (with "*" meaning "all commands") and the API layer (openbb_core/api/router/commands.py) applies them after the command runs.

Three flags govern their behaviour:

  • on_command_output: bool — enable the post-execution hook.
  • command_output_paths: list[str] | None — restrict to specific endpoint paths; None means every command.
  • immutable: bool = True — if False, the hook may modify OBBject.results in place. Mutable hooks additionally require system_settings.allow_mutable_extensions=True.
  • results_only: bool = False — return just OBBject.results over the REST API instead of the full envelope.
[project.entry-points."openbb_obbject_extension"]
my_hook = "openbb_my_hook:ext"
# ext = Extension(
#     name="my_hook",
#     on_command_output=True,
#     command_output_paths=["/equity/price/historical"],
#     immutable=False,
# )

Because these hooks run on every matching response, they are gated by an explicit opt-in: system_settings.allow_on_command_output (env: OPENBB_ALLOW_ON_COMMAND_OUTPUT) must be True, or instantiating the Extension will raise. Mutating hooks need allow_mutable_extensions (env: OPENBB_ALLOW_MUTABLE_EXTENSIONS) on top of that. Treat on_command_output extensions as code that runs against every result — only install them from sources you trust.

Console script: openbb-build

openbb-core installs one console script:

openbb-build

It is defined in openbb_core/build.py (openbb-build = openbb_core.build:main). It imports the openbb package in a subprocess, which triggers static-client generation when the generated package is missing or stale, and falls back to calling openbb.build() explicitly if the import did not rebuild. Run it after installing or upgrading any extension to regenerate openbb/package/ and reference.json.

What lives inside the package

  • openbb_core.provider — base classes (Data, QueryParams, Provider, Fetcher) and the registry that turns openbb_provider_extension entries into a queryable map of (standard_model, provider) -> Fetcher.
  • openbb_core.provider.standard_models — the shared Pydantic schemas (equity prices, options chains, CPI, treasury rates, etc.) that every provider maps onto. This is what makes "swap providers without changing caller code" possible.
  • openbb_core.app.router.Router — a thin wrapper around FastAPI's APIRouter used by openbb_core_extension packages to declare commands.
  • openbb_core.app.command_runner — the execution path used by the generated Python client: resolves provider choice, runs the matching Fetcher, applies post-processing hooks, and returns an OBBject.
  • openbb_core.app.static.package_builder — walks the merged router and emits the typed openbb/package/ modules plus reference.json. This is what openbb-build ultimately drives.
  • openbb_core.api.rest_api — the FastAPI app (app) built from the same routers, with auth hooks and OpenAPI generation. Serve it with any ASGI server.
  • openbb_core.app.extension_loader — the entry-point discovery layer described above.
  • openbb_core.app.service — system settings, user settings, credentials, and auth services shared by the runtime and the REST API.
  • openbb_core.app.logs — structured logging with rotating file handlers.

Prerequisites

  • Python >=3.11,<4
  • For extension authors: working knowledge of FastAPI and Pydantic v2.

Installation

pip install openbb-core

You normally do not install openbb-core directly — openbb and provider extensions pull it in. Install it explicitly only when authoring an extension.

Running the REST API

uvicorn openbb_core.api.rest_api:app --reload

The same router graph that backs from openbb import obb is exposed over HTTP, with OpenAPI available at /docs.

Bugs

Report bugs on GitHub.

License

Apache-2.0. See LICENSE.