Some top-level configuration variables, like addresses, can be auto-generated (though with the potential for conflicts which we can accept)
Currently we don't do this (due to the possibility of conflicts), but we could. In particular it would be useful for, e.g. docker-compose .env files, and for command-line arguments to auto-generated clients.
Ideally however this is done, it should not be commingled with the system's generated code. Perhaps it should just be an "env.sh" file or equivalent, with instructions that users should manually source the env file if they want these variables to be set automatically (alternatively they can manually set the variables).
One internal change that we could make to facilitate this is that the golang namespace could search for configuration values in both environment variables (which it doesn't currently do) as well as cmd line flags (which is the way it currently does it).
JonathanMace
commented
10 months ago
Some top-level configuration variables, like addresses, can be auto-generated (though with the potential for conflicts which we can accept)
Currently we don't do this (due to the possibility of conflicts), but we could. In particular it would be useful for, e.g. docker-compose .env files, and for command-line arguments to auto-generated clients.
Ideally however this is done, it should not be commingled with the system's generated code. Perhaps it should just be an "env.sh" file or equivalent, with instructions that users should manually source the env file if they want these variables to be set automatically (alternatively they can manually set the variables).
One internal change that we could make to facilitate this is that the golang namespace could search for configuration values in both environment variables (which it doesn't currently do) as well as cmd line flags (which is the way it currently does it).