Re: [BuildStream] bst CLI design and consistency (UI)

[Chandan Singh <chandan chandansingh net>]

Hi all,

The aim of this message is to summarize the actions taken/planned
based on this thread:

1. DONE: #814 [1] was created to introduce `bst source` command group.
This work is now complete, `track`, `fetch` and `source-checkout` have
been removed as top-level commands, and added to the `bst source`
group.

2. TODO: #822 [2] was created to move `checkout`, `pull` and `push`
under the new `bst artifact` command group, and mark the current
variations as obsolete.

3. TODO: #771 [3] was created to support multiple elements in `bst
checkout`/`bst artifact checkout` and `bst source checkout`. The issue
has been updated to reflect the outcomes from this discussion.

4. WIP: !909 [4] has been created to support multiple elements in `bst
shell`. Based on some of the earlier discussions, the new version  of
this MR will use `--` as separator for the elements and the command,
rather than having to specify multiple element using `-e`.

Cheers,
Chandan

[1]: https://gitlab.com/BuildStream/buildstream/issues/814
[2]: https://gitlab.com/BuildStream/buildstream/issues/822
[3]: https://gitlab.com/BuildStream/buildstream/issues/771
[4]: https://gitlab.com/BuildStream/buildstream/merge_requests/909

On Mon, Dec 10, 2018 at 7:59 PM Chandan Singh <chandan chandansingh net> wrote:
> Great! Since it seemed like we had agreement for the most part, I have
> created !1003 [1] for this change. At present, I have opted for the 2b
> approach mentioned above, i.e. marking the old commands as obsolete
> (that's the right word, thanks Jürg). So, they will error out
> referring users to use the `source *` versions of the commands.
>
> In case anyone has strong preferences about how to handle the
> deprecation/removal process, please reply either to this thread or on
> the merge request.
>
> [1]: https://gitlab.com/BuildStream/buildstream/merge_requests/1003
>
> Cheers,
> Chandan
> On Mon, Dec 10, 2018 at 11:47 AM Jürg Billeter <j bitron ch> wrote:
> > Hi Chandan,
> >
> > On Fri, 2018-12-07 at 18:53 +0000, Chandan Singh wrote:
> > > A couple of questions to decide before we can proceed with this:
> > >
> > > 1. Click commands can be marked as "hidden", which will hide them from the help
> > >    text output. But, this feature is only available since Click 7.0 that was
> > >    released in September earlier this year. Are we okay with declaring
> > >    Click 7.0 as a minimum requirement?
> >
> > As click is a pure Python dependency, I don't see an issue with this.
> >
> > >    If we were to do this, _frontend/cli.py would look something like what I've
> > >    done in this commit:
> > >    https://gitlab.com/BuildStream/buildstream/commit/4502a6d94193918655299fcd4be12acc0e8987d0
> >
> > I think we should use the word 'obsolete' instead of 'deprecated', as
> > 'deprecated' would indicate that it still works, as I understand the
> > terms.
> >
> > > 2. Reg. old top-level names, seems like we have a few options:
> > >
> > >    a. Mark them as aliases of new commands, but print a deprecation warning
> > >    b. Provide an error message referring to use the new command
> > >
> > >    Keeping in mind that there are other CLI changes that are happening in this
> > >    release (like workspace rework, artifact etc.), it would make sense to
> > >    pick one approach and stick to it. So, which one do people prefer?
> > >
> > >    I am leaning towards 2b as it attempts to teach users the new behavior
> > >    rather than fixing it from them, and has lower burden on the mainteiners,
> > >    but I don't really have strong opinions either way.
> >
> > 2b sounds fine to me but I also don't really have a strong opinion
> > either way.
> >
> > Cheers,
> > Jürg