Describe the feature
I'm proposing using some kind of schema standard for the config which can produce the rust types and their relationship, so that both reth and any configuration language can easily stay in sync.
Additional context
I'm looking through the docs in order to write a nix module for reth for ethereum.nix using nixpkgs RFC 42, and while doing so realized that while the pattern in the docs may work for trial and error as needed, it doesn't really give you a robust spec with all features laid out.
I ended up having to look at the rust code in order to fully understand it and write a compatible nix module. As time goes on, this means more human eyes will have to do the same just to keep the config options in sync. If a schema file were to exist, it could be used with a build.rs file which produces the types at compile time, adding negligible overhead to the reth project, while making it much easier for downstream project to stay in sync with reth's config options.
Describe the feature
I'm proposing using some kind of schema standard for the config which can produce the rust types and their relationship, so that both reth and any configuration language can easily stay in sync.
Additional context
I'm looking through the docs in order to write a nix module for reth for ethereum.nix using nixpkgs RFC 42, and while doing so realized that while the pattern in the docs may work for trial and error as needed, it doesn't really give you a robust spec with all features laid out.
I ended up having to look at the rust code in order to fully understand it and write a compatible nix module. As time goes on, this means more human eyes will have to do the same just to keep the config options in sync. If a schema file were to exist, it could be used with a
build.rsfile which produces the types at compile time, adding negligible overhead to the reth project, while making it much easier for downstream project to stay in sync with reth's config options.