Hi Chandan,
On Mon, 2020-10-05 at 17:36 +0100, Chandan Singh wrote:
> Hi,
[...]
> > > In this case, I think it would be sensible to at least have an option to
> > > display the same pipeline heading (to stderr, which is considered UI, not
> > > output) in `bst show`, or to just display the heading to stderr
> > > unconditionally there... I think this should essentially satisfy your
> > > expressed use case without adding much or any API surface.
> > >
> > > Thoughts ?
> > >
> > That fixes my issues, yes.
> > something like `bst show --heading`
>
> I'd be +1 for some command to query system info like cache usage etc.
> If such a flag was added as-is, note that it'd only work in the
> context of a BuildStream project. Some comments on that behavior
> follow.
>
> Currently all `bst` CLI operations run with the `app.initialized()`
> context, and one of the first things it does is to make sure that we
> have a project to work with. So, if we want this to work even outside
> the context of a project, we might need to think about offering some
> CLI commands that don't require an initialized context. Maybe
> something like `bst system info`. This would leave the door open for
> other `system` commands like cache pruning etc for future, if we want
> to add those.
To me, this sounds like a perfectly sane separate conversation to have.
I am personally very keen on actually reaching 2.0, and I think we can
agree that such a command group you suggest, while certainly
interesting, need not block 2.0, which is why I think it is crucial at
this point to have granular conversations which we can conclude more
easily, and reach 2.0.
I have personally thought for a long time that the heading information
printed to stderr at `bst show` time would be both helpful and
harmless. It does show a lot of useful information about the loaded
pipeline such as the project options chosen to resolve the element
information output below, all this information deserves more attention
and prominence.
* Can we agree on including the heading information in `bst show`
output unconditionally ?
This is my preference.
* Can we agree on adding a `--print-heading/--no-print-heading`
option to `bst show`, and add a user configuration so that the
user can decide their preference ?
I'm much less keen on this, as it would require another
conversation about where to put user preference options in
the config file which pertain to how the user prefers to see
`bst show` output.
I think that we can safely add the heading unconditionally now,
and it would not be a breaking change to add such configuration
in the future at some point if it became a strong desire.
Cheers,
-Tristan
