Remove notion of "custom catalogs" from agent SDK#705
Remove notion of "custom catalogs" from agent SDK#705nan-yu wants to merge 1 commit intogoogle:mainfrom
Conversation
There was a problem hiding this comment.
Code Review
This is a substantial but well-executed refactoring that removes the concept of "custom catalogs" needing runtime resolution, in favor of pre-bundled, self-contained catalogs. The changes centralize schema and validation logic, simplify the A2uiSchemaManager API, and improve the overall architecture. The test suite has been commendably updated to cover the new structure. I have one suggestion for a minor performance optimization.
a2a_agents/python/a2ui_agent/src/a2ui/inference/schema/manager.py
Outdated
Show resolved
Hide resolved
aaf183d to
27bb573
Compare
|
/gemini summary |
Summary of ChangesThis pull request significantly refactors the A2UI SDK's approach to managing UI component catalogs. By eliminating the distinction of 'custom catalogs' and introducing a unified Highlights
Changelog
|
27bb573 to
7c31917
Compare
7c31917 to
09f576f
Compare
The basic catalog maintained by the A2UI team has no difference from third-party catalogs. This PR removes the notion of custom catalogs. Each catalog provided at runtime should be independent and immutable. At build time, catalogs can refer to components from other catalogs. They need to be bundled into a free-standing one using the `tools/build_catalog/build_catalog.py` script. Fixes google#650
09f576f to
268c25f
Compare
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Thanks for fixing this!!
| """Returns a CatalogConfig for the basic catalog.""" | ||
| return cls( | ||
| name=BASIC_CATALOG_NAME, | ||
| catalog_path="", # basic catalog doesn't need a path from the user |
There was a problem hiding this comment.
Why doesn't this need a path? Otherwise, the core code won't know where to load it from, right?
There was a problem hiding this comment.
The basic catalog and other core schemas (server-to-client and common types) are bundled directly within the SDK. pack_specs_hook.py packs the specs into the package assets. The SDK then loads them as package resources. We only require a path when a user is loading a custom catalog from their own filesystem.
| examples_path: Optional[str] = None | ||
|
|
||
| @classmethod | ||
| def for_basic_catalog(cls, examples_path: Optional[str] = None) -> "CatalogConfig": |
There was a problem hiding this comment.
Can we move this to a top-level function in a different file, perhaps even a different folder, e.g. inference/basic_catalog or something?
That makes the conceptual separation clear, and avoids us accidentally sprinkling basic catalog assumptions into the core library. Ideally, it would be possible for us to publish basic catalog support as a completely separate library which depends on the core inference library.
There was a problem hiding this comment.
+1 on this, then we can run the basic catalog through the sdk like any other catalog
| ) | ||
| if not basic_catalog_schema: | ||
| basic_catalog_schema = {} | ||
| basic_catalog_schema = _load_basic_component(version, CATALOG_SCHEMA_KEY) |
There was a problem hiding this comment.
Ideally, avoid having this special cased logic. I wonder if we can publish the basic catalog schema as a JSON file bundled with the library?
Or perhaps the parameter of CatalogConfig could actually just be a "CatalogProvider" which could either be a FileReadingCatalogProvider which reads a JSON file on disk, or just an InlineCatalogProvider which returns a catalog baked into Python code as a string constant (so it's easy for us to create for the basic catalog).
| return cls( | ||
| name=BASIC_CATALOG_NAME, | ||
| catalog_path="", # basic catalog doesn't need a path from the user | ||
| examples_path=examples_path, |
There was a problem hiding this comment.
maybe just examples_paths=
versus doing an ls of a directory? what if there .git file in that directory?
| """Determines the catalog to use based on supported catalog IDs. | ||
|
|
||
| If neither inline catalogs nor supported catalog IDs are provided, the basic catalog is used. | ||
| If neither inline catalogs nor client-supported catalog IDs are provided, the first agent-supported catalog is used. |
There was a problem hiding this comment.
is it first in the client_capabitilities or first in the supported_catalogs?
| self._schema_manager = ( | ||
| A2uiSchemaManager("0.8", basic_examples_path="examples") if use_ui else None | ||
| A2uiSchemaManager( | ||
| "0.8", |
There was a problem hiding this comment.
maybe make some consts here?
Description
The basic catalog maintained by the A2UI team has no difference from third-party catalogs.
This PR removes the notion of custom catalogs. Each catalog provided at runtime should be independent and immutable. At build time, catalogs can refer to components from other catalogs. They need to be bundled into a
free-standing one using the
tools/build_catalog/build_catalog.pyscript.Fixes: #650
Pre-launch Checklist
If you need help, consider asking for advice on the discussion board.