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 ?
Cheers,
-Tristan
> $ bst query-config --list-possible-keys
> sourcedir: string folder to store the sources
> artifactdir: string folder to store the cached artifacts
> ...
> logdir: string folder to store the logs
>
> $ bst query-config --show-config
> (result of print(yaml_map here))
>
> $ bst query-config --key cachedir
> cache-dir is only availble on buildstream 2.0, please check if you are
> using the correct version
>
> $ bst query-config --key "projects.gnome"
> gnome: {
> strict: false
> }
>
> $ bst query-config --key "logdir"
> /data/something/log
>
> This way I could have queried the current file and folder used for
> artifacts withotu assuming that the configuration file was correct - I
> still don't know that it is.
>
> Tougths?
> Tomaz
