On Mon, Oct 5, 2020 at 3:12 PM Tristan Van Berkom < [email protected]> wrote:
> Hi Tomaz, > > > On Oct 4, 2020, at 11:41 PM, Tomaz Canabrava <[email protected]> wrote: > > > > Hello, > > > > I have only one configuration file for buildstream, on > > ~/.conf/buildstream.conf, and I configured as: > > > > $ cat ~/.config/buildstream.conf | grep artifa > > artifactdir: /data/Projects/Buildstream/build/artifactdir > > > > but for some reason my buildstream assumed that it should store my > > artifacts on ~/.cache/ filling up completely my disk and I had to create > a > > bootable usb stick using my wife's computer, as I could not even login > > anymore (no space on /tmp, no space on /), /data my old 2tb HDD that I > use > > for compilation. > > My sympathies, this was an unfortunate experience to have encountered > indeed. > > > 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`
