You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When configuring an execution run, users might ask which parameters are available for each module/action/package.
Haddock3 should have a CLI that could pull the parameters from the module and generate a .toml with its default values. In fact, we could have an actual "config generator" CLI able to create config.toml files from user requests. Given a menu with the available modules, the users would select the order of modules to execute. Then, the CLI should create a config file containing the default parameters as pulled directly from the modules' signature.
The text was updated successfully, but these errors were encountered:
I understand your point. You are right about the webserver. However, I think having only the webserver leaves the command-line users a bit unattended. But overwhelming users with 1800 params is also not a good idea. Each module will have much less parameters but nonetheless they are many. We can have a three layers params as for HADDOCK2, such as, novice, medium, and guru. Depending on the level, it gives you more or less parameters.
When configuring an execution run, users might ask which parameters are available for each module/action/package.
Haddock3 should have a CLI that could pull the parameters from the module and generate a
.toml
with its default values. In fact, we could have an actual "config generator" CLI able to createconfig.toml
files from user requests. Given a menu with the available modules, the users would select the order of modules to execute. Then, the CLI should create a config file containing the default parameters as pulled directly from the modules' signature.The text was updated successfully, but these errors were encountered: