GNOME.org
 

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

On Thu, Dec 13, 2018 at 12:09 PM Tristan Van Berkom
<tristan vanberkom codethink co uk> wrote:


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


Again, my position is that these things are different and can be handled
differently.


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


No worries, I think I could have been clearer.


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


This is exciting!

In this case I will make an MR to:

o Remove auto-init
o Remove the immediate 'are you sure?' prompts from:
    o bst workspace reset
    o bst workspace close --remove-dir
o Update NEWS accordingly
o Maybe emove the prompt namespace from buildstream.conf

This would make me very happy :)


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.


I think I wasn't clear here, I meant 'consistent with the other commands
as they currently are', i.e. '--force or fail' with no prompts.

So we would have:

    $ bst workspace reset --force app.bst
    .. ok does reset ..
    $ bst workspace reset app.bst
    Refusing to do unforced reset, please run again like so:

        bst workspace reset --force app.bst

    $ echo $?
    1

This is the thing I'm saying would be odd :)


[...]

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

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.


It's cool that we've boiled it down to the core disagreement,
I'm happy to see we agree about the other stuff.


[...]

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


Yeah I agree that there's not an immediate need, it could be planned for and
deferred just like with '--assume-abort'. I can imagine it being useful
in scripts that might drive bst interactively with the user, I don't actually
have such a script as yet.


If we start with:

  -f/--force
  -s/--safe

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.


Yup, sounds good to me.


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.


 --safe

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

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


Yup agreed, I like them about the same too.

It's just the lack of clarity that bothers me. Once you know about the prompts,
it's really clear that '--assume-yes' means 'yes' etc.

For '--safe' I think it's unclear precisely what safety you're
getting, since you
don't answer 'safe' at the prompt.


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 :)


Aha, this makes sense to me now, thanks! I agree about the
approaches that exist.

When I follow the second approach, I find that the design that most
appeals is '--force or fail'. I think it makes the thing simpler overall and
is consistent with the UNIX programs I use.



Cheers,
    -Tristan



Cheers!
Angelos
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]