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
