Configurations of runs are constantly evolving and growing in complexity, as new exploratory use cases arise. Specifying run configurations is very problematic: An explosion of CLI arguments makes for an extremely error prone CLI experience; doing everything with config files is not particularly user-friendly or ergonomic for interactive use.
Perhaps TUIs would provide a good alternative which sits somewhere between CLIs and config files. The TUI could give much better interactive feedback on the validity of parameters than the CLI and config files ever could (at least without resorting to proc-macro-parsed-config-file-in-Rust).
Configs could be described by a Rust type (similar to clap), and a serialized version of the config used in any run, could be stored along with the data produced, much like the toml config file defining a mlem run is copied to the output directory already. Only this would be more robust. Such serializations could then be used as templates for configs used in subsequent runs, to be edited in the TUI, though there would be an issue with schema evolution.
Similarly, progress reporting could probably be done much better with a TUI, than by writing to stdout. We already use indicatif for progress reporting in makelor, but TUIs might be more appropriate in certain cases.
Configurations of runs are constantly evolving and growing in complexity, as new exploratory use cases arise. Specifying run configurations is very problematic: An explosion of CLI arguments makes for an extremely error prone CLI experience; doing everything with config files is not particularly user-friendly or ergonomic for interactive use.
Perhaps TUIs would provide a good alternative which sits somewhere between CLIs and config files. The TUI could give much better interactive feedback on the validity of parameters than the CLI and config files ever could (at least without resorting to proc-macro-parsed-config-file-in-Rust).
Configs could be described by a Rust type (similar to
clap), and a serialized version of the config used in any run, could be stored along with the data produced, much like the toml config file defining a mlem run is copied to the output directory already. Only this would be more robust. Such serializations could then be used as templates for configs used in subsequent runs, to be edited in the TUI, though there would be an issue with schema evolution.Similarly, progress reporting could probably be done much better with a TUI, than by writing to stdout. We already use
indicatiffor progress reporting inmakelor, but TUIs might be more appropriate in certain cases.