@@ -204,15 +204,22 @@ Each language has a dedicated analysis backend implemented under `cldk.analysis.
204204
205205#### Python
206206- ** Backend:** ` cldk.analysis.python `
207- - ** Tools:** ` codeanalyzer-python ` (Jedi + optional CodeQL), Tree-sitter for source-level parsing
207+ - ** Tools:** ` codeanalyzer-python ` (Jedi + CodeQL, default on ), Tree-sitter for source-level parsing
208208- ** Capabilities:** Symbol table, call graph, class/method resolution, comments/docstrings
209209
210- > ** Note — analysis cache:** The first Python analysis run creates a
211- > ` .codeanalyzer/ ` directory in the project under analysis. It holds the
212- > backend's virtualenv, the CodeQL database (when enabled), and the cached
213- > ` analysis.json ` . It can be large and is environment-specific, so ** add
214- > ` .codeanalyzer/ ` (and ` .cldk-cache/ ` if you persist analysis JSON there)
215- > to your ` .gitignore ` .** Both are already ignored in this repo.
210+ > ** Note — analysis cache:** Analysis artifacts are cached under ` ~/.cldk `
211+ > (override with ` $CLDK_CACHE_DIR ` ): the backend virtualenv and CodeQL
212+ > database under ` ~/.cldk/venvs/<dep_hash>/ ` , and ` analysis.json ` under
213+ > ` ~/.cldk/cache/<key>/ ` . ** CodeQL is enabled by default**
214+ > (` use_codeql=True ` ), so the first analysis of a project builds a CodeQL
215+ > database and provisions the CodeQL CLI — expect a slow cold run; subsequent
216+ > runs on the same source tree are cache hits. Pass ` use_codeql=False ` for
217+ > Jedi-only analysis. The CodeQL flag is part of the analysis cache key, so
218+ > toggling it — or upgrading from a version that defaulted it off — triggers
219+ > a ** one-time** rebuild under a new key (no stale data is served). If you
220+ > instead point ` analysis_backend_path ` / ` analysis_json_path ` inside a
221+ > project, add those directories to your ` .gitignore ` — they are large and
222+ > environment-specific.
216223
217224#### C
218225- ** Backend:** ` cldk.analysis.c `
0 commit comments