Modern CLI tools (git, gcloud, docker, rclone, etc.) allow configuration values to be overridden by environment variables, which can, in turn, be overridden by the values explicitly supplied on the command line.

This enables workflows that use different values for options (and parameters) (e.g., GIT_AUTHOR) and let the developer describe the desired environment using - duh! - environment variables, instead of having to explicitly specify options (and parameters) on the command line (which is error-prone to the point of being unworkable) or remembering to set the global configuration values before each CLI invocation (which is completely unworkable).

Combined with tools like direnv, that set the the environment variables in a directory-specific way, such an approach to environment variables allows setting up different environments and choosing between them based on the directory the CLI tools is invoked in - for example, using different git committer email addresses for projects belonging to different organizations developer participates in.

In case of DevPod, developer should be able to seamlessly use different providers for different groups of projects - e.g., ssh provider for projects in one organization and gcloud provider for projects in another.

This is not currently possible because DevPod does not follow the "traditional" approach to the environment variables.

DevPod CLI itself does not look at any environment variables (other than DEVPOD_HOME); for instance, there is no way to specify context, provider or ide via environment variables.

Some DevPod providers (e.g., gcloud) do employ environment variables for some of the properties (e.g., PROJECT), but the names of those environment variables are too generic; as in the other mature tools, they should be scoped by the tool and the area of functionality (e.g., DEVPOD_PROVIDER_GCLOUD_PROJECT).

Most importantly, even those few (misnamed) environment variables that DevPod does look at are only consulted when the value is not configured in the global configuration (see loft-sh/devpod-provider-gcloud#23).

Ironically, developers of the command-line library that DevPod uses (cobra) publish an add-on to it (viper) that handles (among other things) environment variables the same way all the tools other than DevPod do it; in their own words:

A professional CLI should allow configuration to be specified from multiple sources
with a clear order of precedence. A user might set a default in a config file,
a CI/CD pipeline might override it with an environment variable,
and a developer might override it again for a single run with a command-line flag.

I would like for DevPod to move towards a future where most (if not all) of the options (and parameters) can be supplied via environment variables; at an absolute minimum, since DevPod supports (albeit does not document well) a notion of a context, a "hybrid" approach should be supported: describe multiple environments as DevPod contexts, using devpod ... create and devpod ... use commands for things like provider, ide, etc., but choose which context to apply to a particular DevPod command invocation based on the value of the environment variable DEVPOD_CONTEXT.

Pull request #195 takes first steps in this direction.

@skevetter do you agree in general with this direction of change?

Any suggestions on how to make such changes less repetitive or better in other ways are, of course, welcome ;)

Also: could you please fork the original DevPod gcloud provider? That's the one I use, and I would like to apply the "handle environment variables with correct order of precedence" treatment to it.

Thank you!