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

[Chandan Singh <chandan chandansingh net>]

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