Have you any wisdom to offer on using Rust source as config files, perhaps supported by proc macros?
I have an ever-growing bunch of utilities written in Rust, ranging from the tiny to huge, which are chained together as separate steps in scientific simulations and data analysis. These tend to start off having a clap-based CLI, which tends to become more complicated over time as the need for more parameters, tweaks and use cases emerges.
In one of these, the CLI got so complex and unwieldy that I replaced it with a configuration file written in TOML. However, this feels unsatisfactory, clunky, unergonomical. So I'm wondering whether it would make sense to use Rust source code for the config, perhaps supported by some procedural macros.
Run-time dependence on Rust compiler
Using Rust source as config files would require the user to have a Rust compiler available in order to run the code.
This is research code, so it is continually in flux as new requirements are discovered and implemented on almost a daily basis. Hence, the compiler is effectively a de-facto requirement today. But maybe this would become a problem in the future, when we have explored the problem space more thoroughly and want to provide a working product for others to use.
Liberation from TOML / Direct integration with Rust type system
The complexity of the information that needs to be expressed in the config file keeps growing. Coming up with mappings between TOML and what is usually a Rust datatype, implementing the conversion and testing various constraints is quite a pain, even with the support of serde.
Being able to simply write Rust expressions seems appealing in this context.
Extra compile-time feedback in IDE
Rust-source configs would get edit-time feedback from rust-analyzer, which is going to be orders of magnitude more useful than anything we could get in TOML.
As the code is in flux, the config file parser needs to keep up with the code's evolution. At the moment, such divergences only appear at run-time. Yes, there are tests, but these require extra effort to maintain and still give less direct feedback and give it later than what we would get in Rust-source configs.
Enhanced feedback via proc macros
One feature of these config files is that they must refer to data files in very long-winded locations. It is most irksome to launch a process and only then to discover typos in these names.
Proc macros should be able to issue errors right inside the editor, if some specified input file is missing, or the destination of some output file is not writable.
Can you see any other pros or cons?
Is this a crazy idea: will it cause more trouble than it's worth?
Are you aware of any relevant prior art?