global flags about rack HOT 18 CLOSED

It sure seems like output and auth are both global output flags. I guess we need to find which services are counter to this.

from rack.

I'm guessing file download may be the offender, but that might be about how we style it.

from rack.

Current global flags, with working names (open to debate)

• username
• apiKey
• region
• output or json, csv, 'plain`
• authUrl
• fields
• debug

What else?

from rack.

authURL (naming speculative)
fields (https://github.com/jrperritt/rack/pull/39) will allow users to limit the fields returned in output

from rack.

Why would they need to provide auth url?

from rack.

output can be plain/table as well.

from rack.

To authenticate to a different endpoint. See here: https://github.com/jrperritt/rack/issues/15, though that may be an admin-only function.

from rack.

Ah, non production. I think it's sensible for that to stay, it's not really admin only like impersonation.

from rack.

Probably --debug also.

from rack.

Under "completeness" we need servers, networks and block storage before cloud files.

from rack.

Closing this. I think we've settled on having global flags.

from rack.

I'm revisiting this issue.

I used the client a bit today, and I find myself being annoyed having to move the cursor so much when manipulating parameters that are currently global.

For example:

$ rack servers instance list
$ rack servers instance list --json
$ rack servers instance list --json region IAD
$ rack servers instance list --json region DFW
$ rack servers instance list --json region ORD

I expect folks to make successive calls like above frequently, and having to move all the way back to rack in the cursor location seems sub optimal.

I realize I'm a bit contrarian to my opinions above, but like I said, this came from using it today.

from rack.

Further examples:

$ rack servers instance list --profile ken
$ rack servers instance list --profile ken-test
$ rack servers instance list --profile production

from rack.

Is it the cli tooling we're using in golang that prevents us from having global flags that can be dropped anywhere after rack?

from rack.

-1 global before service

from rack.

I'm pretty sure we can make any orientation of flags work, but I think we should decide on only one. For example, output and auth flags should either have to go after rack or have to go somewhere after the last subcommand. I don't think we should allow both forms.

from rack.

Countering the -1 with a "consider before service" (my votes count as +.5). Cognitively, the leading/prefix sets up the environment, the trailing/suffix configures the command. That said I had a 30 min discussion with Ken and recognize this is something that can be sussed out when more config file work is testable and more users are playing with it. Also I'm a supernova fanboy. Clearly.

from rack.

Implemented in #108 to allow output and auth flags both before service and after the last subcommand.

from rack.