googleapis / googleapis/librarian
serviceconfig: hardcode API config extensions
- Dominant language
- Go
- Stars
- 45
- Forks
- 61
- Avg merge
- 19h 11m
- Merged PRs (30d)
- 181
Description
There are a number of fields we eventually want to move into service config files. That migration will take time, so as an interim step, we should hardcode these values directly in the Librarian repository in order to create a temporary representation generators can read without requiring a full service-config migration.
This structure should be simple and easy to replace once we start work unified configs: https://github.com/googleapis/librarian/milestone/72
The Rust generator currently depends on these fields, which would ideally be the same across all languages:
- release_level
- service config when it is not in the channel directory (examples: https://github.com/googleapis/librarian/issues/3123)
- title-override
- list of APIs to generate
Python and Go additionally rely on:
- REST numeric enums (https://github.com/googleapis/librarian/issues/3005)
- transports
- `*_grpc_service_config.json` (https://github.com/googleapis/librarian/issues/3004)
PHP and Java additionally rely on:
- *`_gapic.yaml` (https://github.com/googleapis/librarian/issues/3041)
Contributor guide
Research direction
Start by tracing how the Rust, Python, Go, PHP, and Java generators currently obtain their listed configuration fields, especially release_level, service configs, transports, API lists, and language-specific config files. Define a simple Librarian representation that generators can read, then verify that each listed generator can consume the required values without a full service-config migration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, java, php, python, rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100