Hi, <snip>
> > > So I propose something simple, but that *might* solve this kind of > > issue, a > > > new addition to core (as I don't know how to provide this outside core, > > if > > > it's possible I'm all ears) that you can query all the maps and > > definitions > > > from the yaml configuration (or defaults, if none). > > > > I’m not fond of this idea honestly, I think we can get similar without > > adding a whole new command. > > > > First off, every build log starts out by printing all such relevant > > information in the heading, starting with BuildStream version, active user > > configurations, loaded project configurations, and then summary of cache > > keys for the loaded pipeline. > > > > This is printed every build. > > > > > Example usage of the things I imagine: > > > > > > $ bst query-config --config-file > > > /home/username/.conf/buildstream1.bst > > > /home/username/.conf/buildstream.bst > > > > What I mostly dislike about this, is that it would appear to offer some > > kind of interoperability, require API stability, for wrapper scripts to > > consume and presumably do something with the output, but we don’t offer any > > kind of external API guarantees for things like the format of the internal > > artifact cache or source cache directories. > > > > That said, judging from your proposal, the aim is to solve a different > > problem, IIUC you would like a way to quickly inform the user. > > > > 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. - Chandan
