Feature Request: Runtime Configurations with Env Vars #3854

Problem

Developers configure applications at runtime in a variety of ways. Using command-line arguments is a common way; but in some contexts, altering command-line entrypoints to programs can be difficult or impossible. For such scenarios where we cannot alter a program entrypoint, we often use environmental variables to alter program behavior. Often in deployment environments, env-vars can be changed without releases. This flexibility in configuration allows developers to use frameworks in a wider array of contexts, and can generally ease their adoption into existing deployment systems.

ADK provides powerful configuration options through command-line arguments, but so far as I can tell is limited in which values can be set via environmental variables. I'm proposing the solution that modern server frameworks such as uvicorn provide, where configurations can be made both by command-line and by environmental variables. This will provide greater flexibility in runtime possibilities to users.

Solution

The solution should be relatively simple. For command-line arguments such as --session_service_uri or --artifact_service_uri, or other options, users should be able to set an environmental variable such as ADK_SESSION_SERVICE_URI or ADK_ARTIFACT_SERVICE_URI.

This solution should be relatively simple to implement in the ADK python library. Uvicorn implements this through a context_setting map variable in the command implementation:

@click.command(context_settings={"auto_envvar_prefix": "UVICORN"})

This allows users to set variables such as port or host by adding variables with the prefix "UVICORN" to their environment (UVICORN_PORT=...). ADK could take a similar strategy using the prefix "ADK".

@click.group(context_settings={"max_content_width": 240, "auto_envvar_prefix": "ADK"})
@click.version_option(version.__version__)
def main():
  """Agent Development Kit CLI tools."""
  pass

Additional context

1. Solution Scope. This solution is relatively targeted toward configurations on the adk web and adk api_server entrypoints. The solution provided will not resolve other configuration issues, such as how the Uvicorn server picks up configurations. It would be good to extend the solution to cover these extended cases.

2. Potential side-effects. In layered frameworks such as ADK, there can sometimes be conflicting variables that are taken in at different parts of the program. Thus targeting a change in configuration to one part of the app can have an unintended effect on another part of the application. This should not be an issue, as the prefix of the variables should not cause a collision with other frameworks the user may also have in play.

If this solution is good, I'm more than happy to implement a PR here and build some testing for it. Thanks!