Skip to content

Release 6.2.19: link methods return relationship GUIDs (ISSUE-174), ISSUE-173 removals, Pydantic V2 #525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dwolfson merged 7 commits into from
Nov 1, 2026
Merged

Release 6.2.19: link methods return relationship GUIDs (ISSUE-174), ISSUE-173 removals, Pydantic V2 #525

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
a89ddbc
docs(issues): log ISSUE-174, link methods discard the new relationshi…
dwolfson Oct 31, 2026
21fe5bf
fix(omvs): link/attach/setup methods return the new relationship GUID…
dwolfson Oct 31, 2026
787a819
feat(view)!: remove the report-spec sources and dotted paths deprecat…
dwolfson Oct 31, 2026
c09b384
refactor(view): move the report-spec models to Pydantic V2 validators…
dwolfson Oct 31, 2026
2522f33
feat(core): find_note_logs takes graph_query_depth as a named parameter
dwolfson Oct 31, 2026
2745e38
docs: ISSUE-173 to the Appendix; AGENTS.md and view README match the …
dwolfson Oct 31, 2026
b9df37c
chore(release): bump version to 6.2.19
dwolfson Oct 31, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@
- `pyegeria/omvs/*`: service implementations (40+ modules); new API behavior should usually be added here first.
- `pyegeria/models/`: Pydantic models for Egeria API request/response bodies (`models.py`, `collection_models.py`).
- `pyegeria/view/_output_format_models.py`: Pydantic models (`Column`/`Format`/`FormatSet`/`ActionParameter`) backing the report spec registry.
- `pyegeria/view/output_formatter.py` + `pyegeria/view/base_report_formats.py`: materialization/rendering and report spec registry; generated specs live in `base_report_formats.py` under `generated_format_sets` (do not hand-edit), hand-maintained ones under `base_report_specs` (safe to edit). `get_report_registry()` auto-loads an additional CONFIG tier on first call: `pyegeria.report_specs` entry points (alias `trellis.report_specs`; pyegeria's own analytic demos load this way) and the user report specs directory, plus the deprecated `PYEGERIA_REPORT_SPEC_MODULES`/config.json list (warns in 6.2.18, removed in 6.2.19; ISSUE-173). Report specs name analytic functions by registered name; a dotted path is deprecated.
- `pyegeria/view/output_formatter.py` + `pyegeria/view/base_report_formats.py`: materialization/rendering and report spec registry; generated specs live in `base_report_formats.py` under `generated_format_sets` (do not hand-edit), hand-maintained ones under `base_report_specs` (safe to edit). `get_report_registry()` auto-loads an additional CONFIG tier on first call: `pyegeria.report_specs` entry points (pyegeria's own analytic demos load this way) and the user report specs directory; other code registers specs with `register_report_specs()`. `PYEGERIA_REPORT_SPEC_MODULES`, `PYEGERIA_REPORT_FORMATS_*`, config.json's list and the `trellis.*` alias groups were removed in 6.2.19 (ISSUE-173). Report specs name analytic functions by registered name; a dotted path raises `AnalyticFunctionRefused`.
- `pyegeria/view/format_set_executor.py`: side-effect-free FormatSet runner used by the MCP adapter and the `ViewProcessor` in Dr.Egeria; also runs `ActionParameter.analytic_function` (the `extra_find` path) and wraps its result as a `SERIES`/`BAR`/`PIE` Vega-Lite chart when requested.
- `pyegeria/view/analytic_registry.py` + `pyegeria/view/analytic_demo_specs.py`: catalog of analytic functions (`extra_find` targets) and one real demo `FormatSet` per function. A report spec may only name a registered function or a module under `PYEGERIA_ANALYTIC_MODULE_PREFIXES` (ISSUE-169); packages register through the `pyegeria.analytics` entry-point group (ISSUE-172).
- `pyegeria/view/_output_dashboard_sheet_models.py`: `DashboardSheet`/`Placement` — local (pre-Egeria-native) model for user-authored dashboards; built via `md_processing/v2/dashboard_sheet.py`'s processors (`Create Dashboard Sheet`, `Link Report to Dashboard Sheet`, `Add Text on Dashboard Sheet`).
Expand Down
6 changes: 3 additions & 3 deletions CLAUDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -268,12 +268,12 @@ Changes to `pyegeria/` (SDK API, config, report formatting) can break both.
- `create_egeria_bearer_token()` / `set_bearer_token()` propagate tokens to every subclient.

**`pyegeria/view/`** — output formatting and report spec registry
- `base_report_formats.py`: two separate dicts merged by `get_report_registry()` — `generated_format_sets` (auto-generated by `refresh_specs`; do not hand-edit) and `base_report_specs` (hand-maintained BUILTINS, e.g. `Referenceable`; safe to edit directly, `refresh_specs` never touches it). `get_report_registry()` also auto-loads a CONFIG tier on first call: every `pyegeria.report_specs` entry point (alias `trellis.report_specs`; a callable returning a FormatSetDict, or the dict itself — pyegeria's own analytic demo specs load this way, so after changing entry points run `uv sync`), then every `*.json` in the user report specs directory (`PYEGERIA_USER_REPORT_SPECS_DIR` > config.json `"Pyegeria User Report Specs Dir"` > `~/.pyegeria/report_specs`). config.json's `"Pyegeria Report Spec Modules"`, `PYEGERIA_REPORT_SPEC_MODULES` and `PYEGERIA_REPORT_FORMATS_JSON`/`_MODULES` still load but are deprecated: one DeprecationWarning per refresh in 6.2.18, removed in 6.2.19 (ISSUE-173). Each entry loads independently: a failing or label-colliding entry is skipped with a warning (and returned by `refresh_report_specs()`), never blocking the others. **Gotcha:** `config/config.json` is only auto-discovered if `PYEGERIA_CONFIG_DIRECTORY` (or `PYEGERIA_ROOT_PATH`) is set — a bare shell with neither falls back to defaults silently, so a probe script that just imports `settings` may not see config.json values at all; use the `PYEGERIA_USER_REPORT_SPECS_DIR` env var directly when in doubt.
- `base_report_formats.py`: two separate dicts merged by `get_report_registry()` — `generated_format_sets` (auto-generated by `refresh_specs`; do not hand-edit) and `base_report_specs` (hand-maintained BUILTINS, e.g. `Referenceable`; safe to edit directly, `refresh_specs` never touches it). `get_report_registry()` also auto-loads a CONFIG tier on first call: every `pyegeria.report_specs` entry point (a callable returning a FormatSetDict, or the dict itself — pyegeria's own analytic demo specs load this way, so after changing entry points run `uv sync`), then every `*.json` in the user report specs directory (`PYEGERIA_USER_REPORT_SPECS_DIR` > config.json `"Pyegeria User Report Specs Dir"` > `~/.pyegeria/report_specs`). config.json's `"Pyegeria Report Spec Modules"`, `PYEGERIA_REPORT_SPEC_MODULES` and `PYEGERIA_REPORT_FORMATS_JSON`/`_MODULES` were removed in 6.2.19 (ISSUE-173): no longer read, one WARNING log per refresh if still set. Code that isn't an installed package uses `register_report_specs(specs, source=...)` (RUNTIME tier; survives a refresh; same label from the same source is a no-op). Each entry loads independently: a failing or label-colliding entry is skipped with a warning (and returned by `refresh_report_specs()`), never blocking the others. **Gotcha:** `config/config.json` is only auto-discovered if `PYEGERIA_CONFIG_DIRECTORY` (or `PYEGERIA_ROOT_PATH`) is set — a bare shell with neither falls back to defaults silently, so a probe script that just imports `settings` may not see config.json values at all; use the `PYEGERIA_USER_REPORT_SPECS_DIR` env var directly when in doubt.
- `output_formatter.py`: `generate_output()` — materializes elements into MD/LIST/DICT/REPORT formats.
- `_output_format_models.py`: Pydantic models `Column`/`Format`/`FormatSet`/`ActionParameter` — define new specs with these, not raw dicts. `ActionParameter` has two independent execution paths: `function`/`find_method` (element-query, formatted per-column) and `analytic_function`/`extra_find` (a plain function returning an already-aggregated result — see `output-formats-and-report-specs.md`'s "Analytic functions" section).
- `format_set_executor.py`: `exec_report_spec()` — runs either path; `SERIES`/`BAR`/`PIE` output formats wrap an analytic function's result as a Vega-Lite chart (dispatched before normal Format-row lookup, so no `FormatSet` needs to declare those as a `Format` row).
- `analytic_registry.py` / `analytic_demo_specs.py`: the catalog of analytic functions (`AnalyticFunctionSpec.generic` marks whether what it counts is a parameter or hardcoded) and one real, executable demo `FormatSet` per registered function. Installed packages add entries through the `pyegeria.analytics` entry-point group (`trellis.analytics` as an alias), read lazily on first registry use (ISSUE-172); a spec's optional `declaration` carries result kind, measures with unit/as-of/basis and the four absence sentences (ISSUE-170).
- **Gotcha — `analytic_function` can't name just any module** (ISSUE-169): it must be a registered name, a path a registered entry declares, or a path under `PYEGERIA_ANALYTIC_MODULE_PREFIXES` (default `pyegeria`, `trellis_analytics`); anything else raises `AnalyticFunctionRefused` before import. Report specs (including `metric_trend`'s `metric_path`) should use the registered name: a dotted path there warns with a DeprecationWarning in 6.2.18 and is refused from 6.2.19 (ISSUE-173). A test that injects a fake module must add it to that env var. And a `not_established`/`not_applicable` result comes back as `kind: "absent"` with a sentence in `content`, not as `data` (ISSUE-171).
- `analytic_registry.py` / `analytic_demo_specs.py`: the catalog of analytic functions (`AnalyticFunctionSpec.generic` marks whether what it counts is a parameter or hardcoded) and one real, executable demo `FormatSet` per registered function. Installed packages add entries through the `pyegeria.analytics` entry-point group, read lazily on first registry use (ISSUE-172); a spec's optional `declaration` carries result kind, measures with unit/as-of/basis and the four absence sentences (ISSUE-170).
- **Gotcha — `analytic_function` can't name just any module** (ISSUE-169): it must be a registered name, a path a registered entry declares, or a path under `PYEGERIA_ANALYTIC_MODULE_PREFIXES` (default `pyegeria`, `trellis_analytics`); anything else raises `AnalyticFunctionRefused` before import. Report specs (including `metric_trend`'s `metric_path`) must use the registered name: from 6.2.19 a dotted path there raises `AnalyticFunctionRefused` (ISSUE-173). A test that injects a fake module must add it to that env var and, if a report spec names it, register it by name too. And a `not_established`/`not_applicable` result comes back as `kind: "absent"` with a sentence in `content`, not as `data` (ISSUE-171).
- `_output_dashboard_sheet_models.py`: `DashboardSheet`/`Placement` — a local (not yet Egeria-native) model for user-authored dashboards, built via Dr.Egeria's `Create Dashboard Sheet`/`Link Report to Dashboard Sheet`/`Add Text on Dashboard Sheet` (`md_processing/v2/dashboard_sheet.py`).
- Generated report specs follow `{Type}-DrE-{Basic|Advanced}` naming; carry an optional `family` string for discovery. Columns are the Create command's (input) attributes; display-only server-returned columns (e.g. the ISC mermaid graphs) go in `GENERATED_EXTRA_COLUMNS` in `commands/tech/gen_report_specs.py`, never in the compact spec.

Expand Down
Loading
Loading