Summary

When codeanalyzer provisions/detects the analysis environment for a target project, it uses the system default interpreter (python3). On hosts where that is 3.14 (current Homebrew/macOS default), jedi's parser rejects the environment — parso ships one hardcoded grammar file per Python version, and parso 0.8.4 only carries 3.6 … 3.13 (no grammar314.txt). Every file then fails with:

ERROR    Failed to process <file>: Python version 3.14 is currently not supported.

…and the run still completes "successfully" with an empty symbol table (0 modules, exit 0). The failure is the analysis environment's version, not the interpreter codeanalyzer itself runs under — no_venv=True (which reuses the current process's interpreter) works fine on the same host when that process is on ≤3.13.

Repro

On a machine whose python3 is 3.14.0:

from codeanalyzer.core import Codeanalyzer
from codeanalyzer.options import AnalysisOptions
from codeanalyzer.config import OutputFormat

opts = AnalysisOptions(input=Path("anyproject"), output=None,
                       format=OutputFormat.JSON, skip_tests=True)
with Codeanalyzer(opts) as a:
    analysis = a.analyze()

len(analysis.application.symbol_table)   # 0 — every module errored and was skipped

Observed against a 73-module project (cldk python-sdk): 74s run, per-file ERROR logs, modules: 0, no exception. Same run with no_venv=True under a 3.12 interpreter: 73 modules, 107 classes, 763 callables.

Proposed solution

When provisioning the environment, prefer an interpreter parso actually supports: walk python3.13, python3.12, … on PATH and pick the newest version that jedi/parso accepts, falling back to the system default only if none is found. The supported ceiling can be derived at runtime (e.g. from parso.utils.parse_version_string / the shipped grammar set) rather than hardcoded, so the same logic keeps working when 3.15 lands and when parso adds 3.14.

Found while verifying the cldk python-sdk 2.0.0-rc.1 bump against 1.0.2.