Re: [BuildStream] Proposal: bst commands don't fetch elements implicitly

[Gökçen Nurlu <gokcennurlu gmail com>]

Hi,

I would like to start by adding a related merge request link to show
how it could look like;

https://gitlab.com/BuildStream/buildstream/merge_requests/910#proposed-changes

It took some time to understand each commands' before and after behaviour, make
the changes and tests pass :) It currently adds  `--fetch` but as I stated in
my inline comments below, `--no-fetch` starts to make more sense to me now.

Sander Striker via BuildStream-list <buildstream-list gnome org>, 31
Eki 2018 Çar, 11:24 tarihinde şunu yazdı:
> Hi,
>
> On Sun, Oct 28, 2018 at 2:19 PM Phil Dawson via BuildStream-list <buildstream-list gnome org> wrote:
> > Hi all,
> >
> > This is a write up of a discussion which happened at the Manchester
> > gathering after originally being raised at [1].
> > If we wish bst to follow the principle of least surprise, we should
> > minimize the number of operations performed implicitly when invoking
> > bst commands. To this end, it is proposed here that we change the
> > default behaviour of bst commands such that sources are not fetched
> > unless this is explicitly requested.
>
>
> Consistency typically helps in preventing surprising behavior, as raised in [1].
> That said, let's aim for the best user experience here.  It might be that the other
> commands mentioned, for example bst [artifact] checkout, should actually pull
> (but not build), implicitly.

In `bst {pull,push,track,checkout}` commands the current behaviour is to fetch
the related junction(s). I think that behaviour should be tied to a flag,
either `--fetch` or `--no-fetch` because user might have no information
about a junction s/he is about to fetch. It might be a big one, might take time.
Additionally, adding one of those flags would make the mentioned commands to
error out and so they could be used to test different things.

On the second thought, though, `--no-fetch` instead of `--fetch`
sounds better for
UX.

> > Note that as this proposal would alter BuildStream's cli, any
> > implementation should be completed prior to the 1.4 release.
> > Current Behaviour
> > ------------------------------
> > Currently BuildStream will automatically fetch sources which are not
> > cached when running the following bst commands:
> > - workspace open
> > - workspace reset
> > - source-bundle
> > - shell (with --build option)
> > - build
> > The exception to the above is junction elements, which are fetched at
> > load time by build, fetch, track, pull, push and checkout.
> > Proposed Behaviour
> > ---------------------------------
> > Only `bst build` should fetch sources by default. There is an option
> > like --fetch for the remaining commands. These should only fetch
> > elements if this option is present.
>
>
> It seems a bit silly to not have workspace open implicitly fetch.  The purpose of this command is to 
> interact with the sources.  The same goes for source-checkout.  I am
> unclear on workspace reset.  Maybe you can explain that case a bit more?

Workspace-open (and non-soft workspace-reset) doesn't fetch at the
moment unless you
provide `--track` - but what happens if you just want the current ref?
I think it needs
fetching by default + `--no-fetch` to disable that.

> And when SourceCache makes its debut, I would want the option for bst build to
> not fetch sources either, and only rely on what is available in SourceCache.
>
> > If unfetched sources are required and the --fetch flag is not given,
> > the command should should fail and recommend the user run a bst fetch
> > command or the repeat the command with the --fetch option.
>
>
> This seems a bit silly if it is going to be the common case.  If you tell me what to
> run, why don't you take care of it for me?
>
> > Alternatively,
> > if running in interactive mode, the user should be presented with the
> > option to fetch, continue, quit etc.
> > [1] https://gitlab.com/BuildStream/buildstream/merge_requests/820#note_104008640
>
>
> Cheers,
>
> Sander
>
> > Best regards,
> > Phil
> > _______________________________________________
> > BuildStream-list mailing list
> > BuildStream-list gnome org
> > https://mail.gnome.org/mailman/listinfo/buildstream-list
>
> --

Best,
Gokcen