53d4dcc46d
* 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 Workflows
This directory contains the workflows for the OpenBB 🦋 Project. The workflows are:
📑 Deploy to GitHub Pages
This GitHub Actions workflow is responsible for building the documentation and deploying it to GitHub Pages. This workflow is triggered when a new change is pushed to the main or release branch of the repository, and the documentation is published to GitHub Pages.
Branch Name Check
Objective: To check if pull request branch names follow the GitFlow naming convention before merging.
Triggered by: A pull request event where the target branch is either develop or main.
Branches checked: The source branch of a pull request and the target branch of a pull request.
Steps:
-
Extract branch names: Using the jq tool, the source and target branch names are extracted from the pull request event. The branch names are then stored in environment variables and printed as output.
-
Show Output result for source-branch and target-branch: The source and target branch names are printed to the console.
-
Check branch name for develop PRs: If the target branch is develop, then the source branch is checked against a regular expression to ensure that it follows the GitFlow naming convention. If the branch name is invalid, a message is printed to the console and the workflow exits with a status code of 1.
-
Check branch name for main PRs: If the target branch is main, then the source branch is checked against a regular expression to ensure that it is either a hotfix or a release branch. If the branch name is invalid, a message is printed to the console and the workflow exits with a status code of 1.
Note: The GitFlow naming convention for branches is as follows:
- Feature branches: feature/
- Hotfix branches: hotfix/
- Release branches: release/<major.minor.patch>(rc)
Deploy to PyPI - Nightly
This workflow is used to publish the latest version of the OpenBB Platform CLI to PyPI. The workflow is triggered at UTC+0 daily by the GitHub Action schedule event.
It does this by first updating the pyproject.toml file with a pre-determined version string of the form <currentVersion>.dev<date>, where <date> represents the current day's date as a 8 digit number.
Then, the code installs pypa/build and uses python -m build to create a binary wheel and a source tarball in the dist/ directory.
Finally, it uses the PyPA specific action gh-action-pypi-publish to publish the created files to PyPI.
Deploy the OpenBB Platform to Test PyPI
The Github Action code Deploy to PyPI is used to deploy a Python project to PyPI (Python Package Index) and TestPyPI, which is a separate package index for testing purposes. The code is triggered on two events:
-
Push event: The code is triggered whenever there is a push to the
release/*andmainbranches. -
Workflow dispatch event: The code can be manually triggered by the workflow dispatch event.
The code sets the concurrency to the group and the option cancel-in-progress is set to true to ensure that the running jobs in the same group are cancelled in case another job is triggered.
The code contains two jobs, deploy-test-pypi and deploy-pypi, both of which have the same steps with slight variations.
The deploy-test-pypi job is triggered only if the pushed branch starts with refs/heads/release/. This job sets up the Python environment, installs the build package using pip, builds binary wheel and source tarball using build, and finally, publishes the distributions to TestPyPI using the pypa/gh-action-pypi-publish@release/v1 Github Action. The password to access TestPyPI is stored as a secret named TEST_PYPI_API_TOKEN.
Similarly, the deploy-pypi job is triggered only if the pushed branch starts with refs/heads/main. This job follows the same steps as deploy-test-pypi, but the distributions are published to PyPI instead of TestPyPI. The password to access PyPI is stored as a secret named PYPI_API_TOKEN.
Note: The code uses the pypa/build package for building the binary wheel and source tarball, and the pypa/gh-action-pypi-publish@release/v1 Github Action for publishing the distributions to PyPI and TestPyPI.
Draft release
This GitHub Actions workflow is designed to automatically generate and update draft releases in a GitHub repository. The workflow is triggered when it is manually dispatched, allowing you to control when the draft releases are updated.
🧹 General Linting
This GitHub Actions workflow is responsible for running linting checks on the codebase. This workflow is triggered on pull request events such as opened, synchronize, and edited, and push events on branches with names that start with feature/, hotfix/, or release/. The workflow also sets a number of environment variables and uses Github Actions caching to improve performance.
It consists of two jobs: code-linting and markdown-link-check.
The first job, code-linting, runs on an Ubuntu machine and performs several linting tasks on the code in the repository, including:
- Checking out the code from the repository
- Setting up Python 3.11
- Installing a number of Python packages necessary for the linting tasks
- Running
codespellto check the spelling of comments, strings, and variable names - Running
blackto check the code formatting - Running
ruffto lint the code (replaces pylint, isort, flake8, and pydocstyle) - Running
tyto check the type annotations
The second job, markdown-link-check, runs on an Ubuntu machine and performs linting of the markdown files in the repository. It uses a Docker container avtodev/markdown-lint to perform the linting.
🏷️ Pull Request Labels
Validate that pull requests do not include the do not merge label.
🚉 Integration test Platform (API)
Run openbb_platform API integration tests,
🖥️ Unit test CLI
Run cli directory unit tests.
🚉 Unit test Platform
Run openbb_platform directory unit tests - providers, extensions, etc.