Re: [BuildStream] Breaking change: changing '--force or fail' to y/n prompts

On Thu, 2018-12-13 at 11:24 +0000, Angelos Evripiotis wrote:
Let me start (for other's sakes) by adding here that the whole reason
we got here, is because through discussion on issue #957, we noticed
that there are commands which require the user to specify `--force`,
and there are commands which prompt the user, and there is no real
reason why we are treating these two categories of activities
The conclusion of that is that we should be consistent across the
board, and behave the same way whenever we are unsure about doing
something that might be possibly destructive.
Again, my position is that these things are different and can be handled

Sorry, I didn't realize this was your position. When I brought it up in
the issue, I was curious how we would go about distinguishing these two
classes of "Cases where BuildStream might do something destructive and
the user should decide something", I'm still not sure we can classify

  'bst workspace reset' always asks you 'Are you sure?',
which is harmful to the user in my opinion. I think it shouldn't ask.

Honestly I agree here, having a command that always unconditionally
asks if you are sure is annoying.

Then again, for an unsuspecting user, they really can lose work by
resetting their workspace - it's a hard call but I wouldn't be against
just removing this particular question entirely if people generally
agree we shouldn't have it.

If we were to make 'bst workspace reset' consistent with the other
commands then you would always have to say '--force', or it would
exit with an error. That seems like odd behaviour to me :)

You would either answer the default interactive prompt that yes, you
are sure, or you would configure it permanently in your config once it
happened to you a couple of times, or yeah, you would write:

  `bst workspace reset --force <element.bst>`

Asides from the awkwardness that in this case it is an unconditionally
destructive command (i.e. it will *always* delete what was previously
in your workspace), I don't see how this consistency is awkward.

   o You are proposing a *lot* of options, due to our failure to find
     an option name which clearly reflects the opposite of "-f/--force".
     While I think we both agree that "-f/--force" is a desirable choice
     due to it being very commonly used in command line tools, I don't
     think we should resort to adding multiple options which have the
     same meaning.
     Something that I think is rather important to the user experience
     is how they learn the tool using `bst <command> --help` and man
     pages, crowding this output with multiple options which have the
     same meaning would be very undesirable I think.
I think the redundancy actively aids understanding - "oh
'--assume-yes' is just like regular '--force' from other commands".
I think long options are good for making scripts readable, so I'm
sure you're
I think the short options '--yes' and maybe '-y', and maybe '-f' are
kinder to folks that are typing this stuff often. Possibly we'd just
have '-f', I haven't checked if that's available on every command yet.
It seems like three options '--assume-yes', '--force', and '-f' wouldn't
be so much to learn. Is it this you're objecting to?

Essentially yes, I am. I'm objecting to adding more switches than are
strictly needed.

You have an unfinished sentence, but yes I agree that having long/short
options is always good.

However, (and I think we differ here), I think that each option which
has a shorthand is still only *one* option for me to consume; it just
has an abbreviation, and the `--help` output makes those clear to the

The option: `-f/--force`, or the option `-y/--yes` are both one option
to me, I am always glad when there is an abbreviation I can use for a
given option, I do not think the abbreviation of the option is
cognitively expensive, but I think having two separate options is.

I think you're perhaps suggesting this set of options:
o --force, -f
o --no-force
o --require-confirmation, --ask
Instead of this set:
o --assume-yes, --yes, --force, -f
o --assume-no, --no
o --require-confirmation, --ask
So you'd be eliminating:
o --assume-yes
o --yes
o --no
o --ask
Does that sound about right?

I honestly dont see the immediate need for `--ask`, as asking is just
the default operation, and can only ever happen in interactive mode

If we start with:


Then I find it unlikely that people will find themselves in situations
where they have explicitly configured it in their configuration to be
forced, but want to be asked for a specific invocation.

How would you feel about omitting the explicit `--ask` option on the
command line at first, and see how this plays out in practice ?

Adding this in the future would not be a breaking change as far as I
can see.

I'd be very happy to eliminate options (preferably only keeping
'--force' and '-f' :)
As I said, I also like the symmetry of '--no-force' with '--force'. I
consider that
secondary to it being ambiguous though, I think that rules it out as useful.
   This I think would communicate that "everything BuildStream does
   will be safe", i.e. no possibly destructive actions would be taken.
I think this is my suggestion! :)
I dropped it because it again isn't as clear as '--force' and friends.
I think maybe we're disagreeing over whether symmetry is more
important than clarity of meaning. I'm on 'team meaning'.

Yes, and I am clearly on 'team symmetry', but I think there is also

With symmetry, even if the meaning is sometimes compromised, you aid
the user's intuition by providing patterns that the user can safely
expect to work.

That said, I do like `-f/--force` and `-s/--safe` probably as much as I
like the `--no-force` option, I am more against having many options
which mean the same thing (and I don't consider the short
options/abbreviations as different options).

I personally don't like `--assume-yes` and `--assume-no` at all, and
the reason for this is because these names are based on the prompt and
the question itself - this feels ambiguous, and the user would need to
have *seen* the question before hand to every know what they want to
reply to it.
I agree with this - I don't like those same things on apt-get or yum either.
I think they're the least-worst option if we must have prompts.
In other words, I think it is backwards to think that the motivation
for adding these options, is to get rid of pesky prompts, rather we
should have names which communicate to BuildStream what to do, and the
fact that the user is asked something when BuildStream doesn't know
what to do, is just an added convenience to the user.
Hmm, I don't understand this paragraph. Please could you say it
again a different way?

I understand that you are coming towards the problem as "I am a user,
and I have prompts I want to have the option to disable", that's the
angle from which you started writing the patches.

I think this is why the proposed names started with "--assume-yes" and
"--assume-no", I also think you agree its not a good naming pattern
from your reply to the last paragraph.

What I mean in different words is... here are two patterns to thinking
about the problem:

  1.) BuildStream asks me questions
  2.) I can override the answers on the command line
  3.) I can set them in my config
  4.) Now the answers go away

The other pattern is:

  1.) I invoke BuildStream without specifying exactly what to do
  2.) I can be more specific by telling it --force or --safe
  3.) I can specify it more permanently in my user configuration
  4.) In the worst case when it remains unspecified, BuildStream will
      ask me anyway before doing anything destructive.

I think that the naming of the options are better if you follow the
second thought pattern, while the first thought pattern leads you to
the `--assume-yes` or `--assume-no` options, and I think these are the
two different viewpoints we have been having when looking at the
problem in general :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]