As mentioned in #1558, users don't want be restricted by a specific project directory structure. Removing config.yaml will enable us in doing that.
Purpose of config.yaml:
- Provide configuration key values.
- Get execution directory location (by validating project directory and which in return, enables us to run commands from anywhere inside the hasura project directory tree.)
Current alternatives available:
-
For 1, all the key/value pairs in
config.yamlcan be provided using CLI flags / ENV vars / .env file (user defined or default.env). -
To set execution directory, we validate project directory by checking if the required file,
config.yamlis found or not. Thus, 2 proves to be a blocker.
Proposed ideas for unblocking 2:
-
Sol 1: Remove complete support for config.yaml and only allow running commands from project root. In this case, pwd will always be treated as the project root.
Cons: User can not run commands from any location inside the project directory tree expect project's root.
-
Sol 2. Remove complete support for config.yaml and define a
--config-fileglobal flag, so that users provide the complete path to the configuration file with every command.Pros: Solves 2 completely. Directory validation can be done using the path provided for the config file (assuming config file provided is infact at the project root) and run commands from anywhere inside the hasura project directory.
Cons: providing the location of the config file while running every command might not provide the best user experience.
We need to choose between allowing users to run commands from anywhere inside the project directory tree and users passing the --config-file with every command.
-
Sol 3: Combining the above, we can define a global flag
--config-fileand makeconfig.yamloptional.In this case, depending on how config is handled:
- User defined config file ie
--conifg-fileflag provided: execution directory derived from config file provided. Commands can be run from anywhere inside the project root. - default config file: what our current workflow is. We can probably extend our support regarding the definition of default config file. One way is to provide options between
config.yaml,hasura-config.yaml, etc. We can add a flag on thehasura initcommand to select which to use. - no config file: pwd is treated as execution directory. Every commands needs to be run from project root.
In all the above cases, configuration key/values read from CLI flags / ENV vars / .env file / config file (if present). If none provided, default values used.
- User defined config file ie
The above provides a reasonable trade-off between the two choices.