TF_VAR in environment should override config files to avoid need for temporary edits to config

Line 175 in 4503211

func DefaultConfigProvider() ConfigurationProvider {

Configuration is processed by first examining config file then, if needed, environment. Thus, to temporarily use another configuration one must remove or edit the config file. I propose the environment values TF_VAR_etc. should override anything found in the config file if set.

hi @jeliker what're the TF_VAR you were referring here? Are they terraform configs, if yes, you might want to check here: https://github.com/terraform-providers/terraform-provider-oci

In general, if you want to use different configs and avoid edit config files you can do either of followings:

add new profile in your config and switch different profiles in your code;
write your own ConfigurationProvider with the customized logic you need;

Thank you for your reply here. I followed to the go sdk source based on errors encountered in terraform provider which were related to included code from here. I posted here because it seemed related to the shared config code and not specific to terraform provider. The issue manifests because a particular terraform provider feature doesn’t support specifying a “profile.” Thus the only option is to relabel a profile in the config DEFAULT. As I examined the code and found that config file presence means environment variables for config values are ignored I thought to suggest this change. It seems reasonable to me that env. ought to override static config and not the other way around. I hope you’ll agree.

…

_____ Jon-Eric Eliker (mobile) Twitter: @jeliker Jabber: jon@eliker.net

On Nov 5, 2019, at 2:03 PM, Jason Yin ***@***.***> wrote: hi @jeliker what're the TF_VAR you were referring here? Are they terraform configs, if yes, you might want to check here: https://github.com/terraform-providers/terraform-provider-oci In general, if you want to use different configs and avoid edit config files you can do either of followings: add new profile in your config and switch different profiles in your code; write your own ConfigurationProvider with the customized logic you need; — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks @jeliker for the reply.

From SDK perspective, we don't know what kind of TF env variables are and TF will have full control about use the variable in config file or via env variable. And that's the reason we give control to customers to provide their own ConfigurationProvider to do customization instead of changing the default behavior for it.

As I recommended before for the two approaches, TF can use either one to achieve this. Thoughts?

Hi @jeliker I am closing this issue, let me know if you still have questions, thanks!

Understood and fair. I will continue pursuit through TF provider.

…

_____ Jon-Eric Eliker (mobile) Twitter: @jeliker Jabber: jon@eliker.net

On Dec 2, 2019, at 1:04 PM, Jason Yin ***@***.***> wrote: Hi @jeliker I am closing this issue, let me know if you still have questions, thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

FYI I opened #318 (somewhat related to this issue, in case you'd be interested)