Skip to content

spec: pin project-level engine-config format (RFC-001 §9.4) - #95

Merged
trendvidia merged 1 commit into
spec/065-report-wire-shapefrom
spec/060-engine-config
Jul 16, 2026
Merged

spec: pin project-level engine-config format (RFC-001 §9.4)#95
trendvidia merged 1 commit into
spec/065-report-wire-shapefrom
spec/060-engine-config

Conversation

@trendvidia

Copy link
Copy Markdown
Owner

Closes #60 (spec item #11). Stacked on #94 (config.proto imports report.proto for ExecutionMode); retarget/merge after #94.

What

  • proto/schema/config/v1/config.proto (new): EngineConfigengine (registered string id), function_libraries, catalog_libraries, strict_validation, default_mode (reuses protowire.schema.v1.ExecutionMode). Build-time artifact loaded from protowire.config.textproto at the project root; never embedded in descriptors; allocates no extension numbers.
  • RFC-001 §9.4 (new section): schema, file name, discovery, precedence; §13 open-question row 2 marked resolved; §14 references + CHANGELOG updated.
  • testdata/schema-extensions/08_engine_config.textproto: golden config exercising every field.

Design decisions (vs. the issue sketch)

  1. Textproto, not a .proto-with-options file. The sketched options file would burn FileOptions extension numbers on non-carrier config, create a schema-less .proto that glob-driven builds sweep into FileDescriptorSets, and force values through the option-value grammar. Textproto is still proto (no-JSON/YAML holds) and gets a real typed message.
  2. Engine id is a registered string ("cel", "starlark", "go"), not an enum — third-party engines need no spec churn; unknown names are startup errors, never fallbacks.
  3. Nearest-config-wins discovery, no merging (the go.mod model) — merge semantics would reintroduce implicit inheritance.
  4. Precedence: per-setting CLI flags > --config <path> > PROTOWIRE_CONFIG (file pointer only, no per-setting env vars) > discovered file > defaults (cel, lenient, collect-all).
  5. Field 6 earmarked (comment, not reserved) for the Recursive message validation depth limits #62 recursion-depth knob.

The issue's second acceptance box (reference Go loader in protocompile) is M1 follow-up implementation work, tracked in the issue comment rather than blocking the spec decision.

Verification

config.proto parses with stock protoc; the golden fixture round-trips through protoc --encode/--decode (105-byte binary).

Resolves spec issue #11 (GH #60).

- proto/schema/config/v1/config.proto: EngineConfig message. Config is
  a textproto file (protowire.config.textproto at project root), not a
  schema-less .proto carrying file options — keeps the no-JSON/YAML
  principle without burning carrier extension numbers or leaking build
  config into FileDescriptorSet artifacts.
- Discovery: upward walk, nearest config wins, no merging (go.mod model).
- Precedence: per-setting CLI flags > --config > PROTOWIRE_CONFIG (file
  pointer only) > discovered file > defaults (cel, lenient, collect-all).
  Unknown engine names are startup errors, never fallbacks.
- default_mode reuses protowire.schema.v1.ExecutionMode from report.proto;
  field 6 earmarked for the #62 recursion-depth knob.
- New RFC-001 §9.4; §13 row 2 resolved; CHANGELOG updated.
- testdata/schema-extensions/08_engine_config.textproto: golden config,
  verified with stock protoc (parse + --encode/--decode round-trip).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant