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 <[email protected]> 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 > >
