Changing the structure of `atmos terraform ...`

[Gowiem]

trafficstars

Describe the Feature

This is just my opinion, but the structure of atmos is a bit funky when compared to most other CLI tools.

I'm referring to this structure: atmos terraform <command> <component> -s <stack> [options].

The atmos required arguments of component + stack being between command + options has thrown me and others off numerous times now.

Expected Behavior

I'm hoping for a more intuitive structure.

Use Case

N / A

Describe Ideal Solution

My ideal structructure: atmos terraform <command> [options] -c <component> -s <stack>

Alternatives Considered

N/A

Additional Context

• If this is of interest to discuss further, I can shed more thoughts on this and try to find examples of new folks that I've introduced to atmos getting hung up on the current structure.

[osterman]

Thanks for the feedback - we'll discuss on our next ARB call when I'm back from vacation.

[nitrocode]

I agree. A non positional flag for component would make it more intuitive for newcomers and for experienced users. I'd be ok with keeping the positional argument for component and adding a --component and -c flag as an option. Then if either the positional was passed in or the explicit flag was passed in, it should work.

If you want that setup now, you could do this with the custom commands configuration.

[nitrocode]

My ideal would be

atmos -c <component> -s <stack> terraform <command> [options]

[aknysh]

we need to support the current functionality (a lot of companies, people and docs are already using it)

[nitrocode]

It could be put in a major version change like 2.x, no? Usually the major version is when we break backwards compatibility.

Or it could possibly be enabled with a switch in atmos.yaml?

[llpham14]

https://cloudposse.atlassian.net/browse/DEV-905