Make argument and flag use consistent across commands

[josh-berry]

Closes #343. See the issue for the full discussion and rationale behind the specific changes made.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cretz]

Not sure we should add a new global alias for this. I think the previous way of changing environment from default was good enough.

[josh-berry]

The alternative is to be inconsistent and have a different --env flag for temporal env. I think this is worse than simply adding a global alias.

I also like the global alias because it uses less visual and cognitive space for what is essentially contextual information. So overall I feel pretty strongly about keeping it.

[cretz]

I don't think it'll get used very much and I think the bar for our second-ever global alias should be a bit higher. Do you want to apply this strong feeling generally or just now to this one? I like our existing stance of rare aliases.

[josh-berry]

This specific one. I think the other options are much less likely to be used, whereas I could see -E being used quite commonly/consistently, especially in ops scenarios where an operator is dealing with multiple environments. (I also agree with having -o for the output format.)

[cretz]

This flag has been here for years and years sans alias, I don't think it's that common, it has value forcing a user to be clear they are changing environments, and I wouldn't expect an alias to change profile/env/context any more than I'd expect aws CLI to have an alias for --profile or kubectl/docker to have an alias for --context.

[josh-berry]

This flag has been here for years and years sans alias, I don't think it's that common

You are ignoring the fact that we are now using it in a different way.

I think it's pretty ugly/amateurish to be forced to mix and match especially for required options:

temporal env set --env prod -k address -v example.com:3233

And I would find

temporal env set --env prod --key address --value example.com:3233

annoyingly verbose.

The only other alternative I could think of is to have a special version of --env on temporal env commands that has a short form, but again, this is inconsistent and therefore surprising.

If you have another suggestion I haven't thought of, I'm all ears.

[cretz]

You are ignoring the fact that we are now using it in a different way.

Not if we're discussing the global alias which is my primary concern. While I don't like it for temporal env subcommands either, I think we can agree we are not using it in a different way for the vast majority of commands.

And I would find [...] annoyingly verbose

This is subjective and not shared by the other example binaries I linked there, so at the least they didn't agree. This new global alias applies to your words from earlier:

It can also sometimes be a deliberate design decision to not have a short-form alias (e.g. for something obscure or dangerous)

Emphasis mine. It is dangerous to change env/profile/context. Regardless, I think aws or kubectl or docker or those similar tools with contextual pieces like this can provide guidance here.

[josh-berry]

Regardless, I think aws or kubectl or docker or those similar tools with contextual pieces like this can provide guidance here.

You are correct about aws, however:

• kubectl has -s for which API server to connect to, though I agree --context has no short-form
• docker has -c for which context to use and -H for which host to use

So the record is rather mixed here.

Regardless, we've exhausted my time budget on this, so I will concede because it's easier to add it in later than it is to remove it if we later decide we don't want it.

[cretz]

👍 I will also concede the -k and -v since the blast radius of your change there is limited if you want to add those back. My bigger concern was this new global alias we were adding.