Having discussed in part 1 a speculative motivation for
a templated language that could be parameterised at the repo level and a given repo's configs validated as fully determined by the config, or not
I'd now like to narrow down how it should be built, in terms of properties that'd constrain it.
We might imagine publishing the components of such a config schema as distinct blocks built out of primitives of TOML/YAML specs.
General properties it would need to be scalable:
- Deterministic - no hidden inputs (time/file system state/...), everything must be explicitly modelled
- Bidirectional - both produce and parse the config
- Composable - stably combine multiple rules (ordering, merge, override, error)
- Addressable - every derivable part needs a stable name to reference/query/report on
- Incremental - only recompute parts of the spec that change (repos/configs), not everything
I'd also like a fast-path local-only mode that doesn't re-check against remote GitHub state.
Running time
But here's the rub: I don't want this to be in Python — I love Pydantic models but I want blink-and-you'll-miss-it speedy validation, and the Python runtime just can't get going fast enough. For anything sitting in a pre-commit hook suite, to me it has to be in Rust.