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

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi Angelos,

I'm going to snip almost everything out here because it is very long
and I cannot easily structure my reply to it...

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
differently.

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.

[...]
> Hopefully you'll prefer to stick with the simpler '--force or fail',
> and instead remove the all 'are you sure?' prompts, let me know!

As you know, I strongly disagree with this, I think it is exactly the
opposite of user friendly, because it forces the user to learn things
which they otherwise would not need to know.

I think whenever the action BuildStream is performing might be
destructive, the default should always be to ask the user interactively
and hold their hand, rather then forcing them to learn a new command
line argument which they might have the burden of remembering in the
future. I consider all the knowledge I need to know about a tool that I
use to be a burden, the less I need to know as a user, the better.

As you also pointed out yourself in the relevant issue, the fact that
sometimes we can only determine whether an activity might be
destructive after loading the pipeline, can also be quite frustrating
if it takes a few seconds to load the pipeline.

For the rest of your mail, here are a few points:

  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.

  o The buildstream.conf changes you suggest present a weird
    inconsistent interface in my opinion.

    First of all, I think it is a pity that the existing keys start
    with a "really-" prefix, the mere fact that these keys are a part
    of a "prompt" group I think is context enough.

    Secondly, the proposed new members have "bst-" prefixes which I
    think is unnecessarily lengthy for a configuration file which is
    already configuring the behavior of the "bst" command.

    Note that the entire "prompt" group in the user configuration
    is added in the development branch and was never in a release as
    far as I can see, changing these keys would not even be a breaking
    change, so it would be good to have consistency here too.

  o I should point out that the activity (4) which you discard, i.e.
    abort everything right away and exit; should still be accessible
    in the interactive prompts.

    This "abort everything right away and exit" is communicated to
    BuildStream when replying ^C to any prompt.


I think overall, for my part I would like a more consistent user
configuration, and I would like to agree on a single word to reflect
the opposite of "-f/--force", finding good names is hard, but this
again comes down to cognitive burden (as a user I don't want the tool
to tell me there are 5 ways to do a thing, that is telling me more
information than I want to know about).

Maybe I should suggest some options:

 --no-force

  You are right the meaning of this is ambiguous, it might mean
  "ask me", but on the other hand it is consistent with how other
  options are expressed, e.g.: `--interactive/--no-interactive`,
  `--strict/--no-strict`, `--verbose/--no-verbose`, etc.

  I wouldn't write it off completely just for it's ambiguity, as it has
  some consistency and I think is still much better than the addition
  of so many different new options.

 --safe

  This I think would communicate that "everything BuildStream does
  will be safe", i.e. no possibly destructive actions would be taken.


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.

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.

Cheers,
    -Tristan