Environment variables are not populated to cmd flags

[clevinson]

Description

Certain client cmd flags historically have been able to be set via environment variables, instead of explicitly always having to set the flag (e.g. CHAIN_ID, FROM, $SIMD_HOME etc.).

This is not currently supported in Stargate and should be.

@anilcse @alexanderbez I've attempted to find documentation of exactly which flags are expected to be supported with a corresponding env var, but can't find clear evidence of the prior behavior. Feel free to add to this description or reply specific flags that should be supported.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[anilcse]

@clevinson previously we had prefix'd ENV variables => flags mapping. So we shouldn't focus on adding specific flags but fix the behaviour as before. Ex: https://github.com/cosmos/gaia/blob/v2.0.14/cmd/gaiacli/main.go#L73-L74 here we configure the prefix and if we need --chain-id flag, it can be set from GA_CHAIN_ID env variable.

From docs: Environment variables can't have dashes in them, so bind them to their equivalent, keys with underscores, e.g. --favorite-color to STING_FAVORITE_COLOR

[anilcse]

@troian from Akash has a hacky fix

We had issues with values from environment variables not populated to flags, especially on client side. for example if I set AKASH_NODE= client never picks it. it became really painful for us, especially during testing edgenet.
we had a fix to our codebase (see this commit: akash-network/node@d2ce9b1), which looks more like a workaround, but allows us to use environment variables.
there are two issues we have discovered.
wrong initialization sequence in PersistentPreRunE . client.SetCmdClientContextHandler was called before server.InterceptConfigsPreRunHandler which does actual work of configuring viper and binding pflags. thats why client never got values from env vars. was it just typo or there that sequence must be followed?
server.InterceptConfigsPreRunHandler still has some issue with binding pflags to viper thats why we did dirty hack with bindFlags

[alexanderbez]

No, the order does not matter.

[troian]

@alexanderbez is it comment to our hack?

[alexanderbez]

Yes :)

[clevinson]

@alexanderbez Can you let me know if you're working on this? If not, we'll do some triaging and get someone from our team on it.

[alexanderbez]

It's not assigned to me and I'm not working on it, nor do I plan to.

[amaury1093]

This comment #8132 (comment) is relevant here, correct @alexanderbez ?

[alexanderbez]

Yes @amaurymartiny. I really suggest we refactor the entire thing.