juju error messages talk about flags instead of options

[James Troup]

| $ juju run --bogus
| error: flag provided but not defined: --bogus
| $

I'm not sure why --bogus is called a flag - even 'juju help run'
refers to as an option.

| $ juju help run | grep flag
| $

| $ juju help run | grep option
| Usage: juju run [options] <commands>
| $

[Anastasia (anastasia-macmood)]

This needs to be fixed in upstream first.

PR against juju/gnuflag: https://github.com/juju/gnuflag/pull/2

[Anastasia (anastasia-macmood)]

Part of Juju dependency update against develop: https://github.com/juju/juju/pull/8059

Before we are completely consistent, we also need to update juju/cmd package.

[Roger Peppe (rogpeppe)]

Go commands generally refer to "flags" rather than "options" (Unix commands
historically use both terms), so another possibility would be to change
the Juju usage messages to use "flag" rather than "option", which would
avoid cluttering the gnuflag code and API.

Personally, I think I'd prefer that approach.

[John A Meinel (jameinel)]

I think Juju has used options since the beginning. Flag also has more of a
connotation of being a simple boolean. "Is the flag set or not", which
works ok for --verbose, but doesn't work very well for "-m mymodel". You
wouldn't really say "set the model flag to mymodel" vs "set the model
option to mymodel".

I do realize that "go" commands do things differently, because the authors
of the standard library are particularly opinionated (they also decided
that they don't like --long options), which generally goes against a lot of
other tools that people are used to.

AFAICT gnuflag exists explicitly because the stdlib flag doesn't support
interspersed args (-f blah positional -x baz), but it is also essentially
our library to mold as we feel it fits. Otherwise we could use something
like spf13/viper and get a lot more functionality for command line parsing.

Anyway, I prefer 'option' myself, mostly because of the ones that take
strings vs the ones that are only booleans.

On Mon, Nov 13, 2017 at 7:36 PM, Roger Peppe <email address hidden>
wrote:

> Go commands generally refer to "flags" rather than "options" (Unix commands
> historically use both terms), so another possibility would be to change
> the Juju usage messages to use "flag" rather than "option", which would
> avoid cluttering the gnuflag code and API.
>
> Personally, I think I'd prefer that approach.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1637821
>
> Title:
> juju error messages talk about flags instead of options
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1637821/+subscriptions
>

[John A Meinel (jameinel)]

Did this get stalled? I think we agreed that we wanted to go with "option" because that is what "juju help" says. But I still see that juju-2.3.4 and develop still says:
$ juju run --bogus
ERROR flag provided but not defined: --bogus

[Anastasia (anastasia-macmood)]

Intermediate step needs to be done in juju/cmd - https://github.com/juju/cmd/pull/56.

Once this lands, we can update dependency and ensure consistency in juju/juju proper.

[Anastasia (anastasia-macmood)]

another necessary juju/cmd PR: https://github.com/juju/cmd/pull/58

[Anastasia (anastasia-macmood)]

PR against juju/juju heading into 2.5: https://github.com/juju/juju/pull/9541

[Anastasia (anastasia-macmood)]

Pr against develop https://github.com/juju/juju/pull/9555