Remove bst shell --use-buildtree=ask

[Jürg Billeter <j...@bitron.ch>]

Hi all,

`bst shell` currently defaults to `--use-buildtree=ask`, which asks the
user whether they want to use a cached buildtree instead of a clean
source tree for build shells. In non-interactive mode it's equivalent
to `--use-buildtree=never`.

I see a few issues with this:

 * If the buildtree is not already available in the local cache, the
   user is asked whether to pull and use the buildtree without knowing
   whether the buildtree is actually available on a configured artifact
   server. I.e., in that scenario it's simply an interactive prompt for
   the `--use-buildtree` CLI option and the user has to respond with
   'try', 'always' or 'never', which seems very odd to me. As far as I
   can tell, no other BuildStream command has a similar prompt.

 * The above 'pull and use' prompt is shown only if both `--pull` and
   `--pull-buildtrees` are specified (the latter is also configurable
   in buildstream.conf but is disabled by default). If we already
   provide an interactive prompt, I'd expect it to be presented even if
   `--pull-buildtrees` is not enabled.

 * The prompt is presented even if `--build` is not specified, however,
   only build shells can actually use buildtrees. This would be easy to
   fix, of course.

 * I'm working towards supporting remote execution without downloading
   blobs. This requires remote cache queries, which will often be
   slower than local cache queries. An interactive prompt after waiting
   for the remote cache queries to complete would make the user
   experience even worse.

I'm proposing to completely drop support for `--use-buildtree=ask`,
defaulting to `--use-buildtree=never` (the current default for non-
interactive usage). Requiring the user to explicitly specify `--use-
buildtree` if they want to stage a cached buildtree seems reasonable to
me.

Any thoughts on this? Does anyone think it's worthwhile to keep support
for `bst shell --use-buildtree=ask`?

It may make sense to make the CLI a bit more convenient while we're at
it. E.g., have `--use-buildtree` imply `--build` as buildtree only
makes sense with build shells. Maybe even rename it to just `
--buildtree` such that the user can type `bst shell --build` to get a
clean build shell and `bst shell --buildtree` to get a shell with a
cached buildtree.

This would require making the click option a boolean flag instead of a
choice, which means that we would also lose `--use-buildtree=try`.
However, I don't see an issue adding a separate `--try-buildtree` flag
for this, assuming we want to keep that functionality.

Cheers,
Jürg

Re: Remove bst shell --use-buildtree=ask

[Chandan Singh <ch...@chandansingh.net>]

Hi Jürg, all,

Apologies for the late reply, but overall +1 for this idea. Some more
comments inline.

On Wed, Oct 14, 2020 at 11:57 AM Tristan Van Berkom
<tr...@codethink.co.uk> wrote:
>
> Hi,
>
> On Mon, 2020-10-05 at 18:55 +0200, Jürg Billeter wrote:
> > Hi all,
> [...]
> > I'm proposing to completely drop support for `--use-buildtree=ask`,
> > defaulting to `--use-buildtree=never` (the current default for non-
> > interactive usage). Requiring the user to explicitly specify `--use-
> > buildtree` if they want to stage a cached buildtree seems reasonable to
> > me.
> >
> > Any thoughts on this? Does anyone think it's worthwhile to keep support
> > for `bst shell --use-buildtree=ask`?
>
> I definitely agree we should drop silly command line semantics which
> only end up adding another prompt.

Agreed.

This is also inline with how the rest of the CLI flags/options work.
The only place where I think the `ask` semantic would make sense is
the user config file. I don't think it makes much sense in the CLI
itself. In the config file, it may make sense to say - "ask me at
build time whether a buildtree should be used or not". Having said
that, I don't think that is of much use personally. If someone has a
use case for it, I'd not be against having a `ask` semantic in the
config file.

But, I think we should definitely remove it from the CLI either way.

> I also think that when launching a shell, we should:
>
>   * Be clear about whether a build tree was requested.
>
>   * If a build tree is requested, the shell should simply fail if a
>     build tree is not available.
>
> I.e. there should be no room for ambiguity, no "Well, if you happen to
> have a build tree around, yeah give me one" kind of thing.
>
> I think this also informs my next answer...
>
> > It may make sense to make the CLI a bit more convenient while we're at
> > it. E.g., have `--use-buildtree` imply `--build` as buildtree only
> > makes sense with build shells. Maybe even rename it to just `
> > --buildtree` such that the user can type `bst shell --build` to get a
> > clean build shell and `bst shell --buildtree` to get a shell with a
> > cached buildtree.
> >
> > This would require making the click option a boolean flag instead of a
> > choice, which means that we would also lose `--use-buildtree=try`.
> > However, I don't see an issue adding a separate `--try-buildtree` flag
> > for this, assuming we want to keep that functionality.
>
> I don't know what is the justification for launching a shell where you
> do not know if you need a build tree or not, ergo, I would favor
> dropping this "try" semantic entirely.

+1

> Another question is implied pulling of the build tree, this I question
> I would rather leave to a dedicated person who is keeping track of
> reviewing the CLI and providing some consistent behavior (Chandan ?).
>
> Personally, I think I would favor never incurring implied side effects,
> I would be surprised if launching a shell starts inadvertently
> downloading a build tree, and I would prefer an experience where:
>
>   * I type `bst shell --use-buildtree`
>
>   * bst says: "Get outta here, I dont have any build tree for you.
>                If you think there is one lying around on some remote,
>                then maybe you aught to go and pull it yourself".
>
>   * I type: `bst artifact pull --buildtree`
>     (and it downloads something)
>
>   * I type `bst shell --use-buildtree`
>     (now it works)
>
> But on this point I digress, if we're going to have implicit side
> effects being triggered, it should be consistent, all or nothing (save
> for `bst build` which is very "special" in it's nature, and stands
> clearly apart from all other commands).
>
> Cheers,
>     -Tristan
>
>

Re: Remove bst shell --use-buildtree=ask

[Jürg Billeter <j...@bitron.ch>]

Hi Tristan,

On Wed, 2020-10-14 at 19:56 +0900, Tristan Van Berkom wrote:
> Hi,
> 
> On Mon, 2020-10-05 at 18:55 +0200, Jürg Billeter wrote:
> > Any thoughts on this? Does anyone think it's worthwhile to keep support
> > for `bst shell --use-buildtree=ask`?
> 
> I definitely agree we should drop silly command line semantics which
> only end up adding another prompt.
> 
> I also think that when launching a shell, we should:
> 
>   * Be clear about whether a build tree was requested.
> 
>   * If a build tree is requested, the shell should simply fail if a
>     build tree is not available.

Sounds good to me.

> I don't know what is the justification for launching a shell where you
> do not know if you need a build tree or not, ergo, I would favor
> dropping this "try" semantic entirely.

I'd certainly be happy with this. I'm not aware of a scenario either
where this would really be useful. I'll update the MR accordingly if
nobody else comes up with a convincing use case.

> Another question is implied pulling of the build tree, this I question
> I would rather leave to a dedicated person who is keeping track of
> reviewing the CLI and providing some consistent behavior (Chandan ?).
> 
> Personally, I think I would favor never incurring implied side effects,
> I would be surprised if launching a shell starts inadvertently
> downloading a build tree, and I would prefer an experience where:
> 
>   * I type `bst shell --use-buildtree`
> 
>   * bst says: "Get outta here, I dont have any build tree for you.
>                If you think there is one lying around on some remote,
>                then maybe you aught to go and pull it yourself".
> 
>   * I type: `bst artifact pull --buildtree`
>     (and it downloads something)
> 
>   * I type `bst shell --use-buildtree`
>     (now it works)
> 
> But on this point I digress, if we're going to have implicit side
> effects being triggered, it should be consistent, all or nothing (save
> for `bst build` which is very "special" in it's nature, and stands
> clearly apart from all other commands).

The proposal on #819 based on previous ML discussions matches your last
paragraph. I.e., consistently pull/fetch as needed for all commands by
default but allow users to disable this in userconfig and add top-level 
CLI options to allow override per invocation. I think this is a
reasonable solution.

Cheers,
Jürg

Re: Remove bst shell --use-buildtree=ask

[Tristan Van Berkom <tr...@codethink.co.uk>]

Hi,

On Mon, 2020-10-05 at 18:55 +0200, Jürg Billeter wrote:
> Hi all,
[...]
> I'm proposing to completely drop support for `--use-buildtree=ask`,
> defaulting to `--use-buildtree=never` (the current default for non-
> interactive usage). Requiring the user to explicitly specify `--use-
> buildtree` if they want to stage a cached buildtree seems reasonable to
> me.
> 
> Any thoughts on this? Does anyone think it's worthwhile to keep support
> for `bst shell --use-buildtree=ask`?

I definitely agree we should drop silly command line semantics which
only end up adding another prompt.

I also think that when launching a shell, we should:

  * Be clear about whether a build tree was requested.

  * If a build tree is requested, the shell should simply fail if a
    build tree is not available.

I.e. there should be no room for ambiguity, no "Well, if you happen to
have a build tree around, yeah give me one" kind of thing.

I think this also informs my next answer...

> It may make sense to make the CLI a bit more convenient while we're at
> it. E.g., have `--use-buildtree` imply `--build` as buildtree only
> makes sense with build shells. Maybe even rename it to just `
> --buildtree` such that the user can type `bst shell --build` to get a
> clean build shell and `bst shell --buildtree` to get a shell with a
> cached buildtree.
> 
> This would require making the click option a boolean flag instead of a
> choice, which means that we would also lose `--use-buildtree=try`.
> However, I don't see an issue adding a separate `--try-buildtree` flag
> for this, assuming we want to keep that functionality.

I don't know what is the justification for launching a shell where you
do not know if you need a build tree or not, ergo, I would favor
dropping this "try" semantic entirely.

Another question is implied pulling of the build tree, this I question
I would rather leave to a dedicated person who is keeping track of
reviewing the CLI and providing some consistent behavior (Chandan ?).

Personally, I think I would favor never incurring implied side effects,
I would be surprised if launching a shell starts inadvertently
downloading a build tree, and I would prefer an experience where:

  * I type `bst shell --use-buildtree`

  * bst says: "Get outta here, I dont have any build tree for you.
               If you think there is one lying around on some remote,
               then maybe you aught to go and pull it yourself".

  * I type: `bst artifact pull --buildtree`
    (and it downloads something)

  * I type `bst shell --use-buildtree`
    (now it works)

But on this point I digress, if we're going to have implicit side
effects being triggered, it should be consistent, all or nothing (save
for `bst build` which is very "special" in it's nature, and stands
clearly apart from all other commands).

Cheers,
    -Tristan