* 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>
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:
- Discover provider, command, and result-type extensions installed in the current Python environment via setuptools entry points.
- Stitch them together into a single typed Python client (
from openbb import obb) and an equivalent FastAPI REST API. - Execute calls against those extensions, normalise the output through shared
Pydantic models, and return a uniform
OBBjectresult 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;Nonemeans every command.immutable: bool = True— ifFalse, the hook may modifyOBBject.resultsin place. Mutable hooks additionally requiresystem_settings.allow_mutable_extensions=True.results_only: bool = False— return justOBBject.resultsover 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 turnsopenbb_provider_extensionentries 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'sAPIRouterused byopenbb_core_extensionpackages to declare commands.openbb_core.app.command_runner— the execution path used by the generated Python client: resolves provider choice, runs the matchingFetcher, applies post-processing hooks, and returns anOBBject.openbb_core.app.static.package_builder— walks the merged router and emits the typedopenbb/package/modules plusreference.json. This is whatopenbb-buildultimately 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.