[marcuscaisey]

Problem

plz query config correctly outputs the values of a plugin config field if it has been explicitly set in .plzconfig. However, it errors if not.

For example, in this repository:

• plz query config plugin.go.gotool outputs //third_party/go:toolchain|go which has been explicitly set in .plzconfig
• plz query config plugin.go.delvetool errors with Failed to get plugin.go.delvetool: Settable field not defined: plugin.go.delvetool

This is annoying for external consumers of these values as they have to hardcode the default values in their logic.

Solution

Update config.Config so that when we fail to look up a value from the "plugin" section of the configuration, we attempt to read the default values from the plugin's .plzconfig.

Default values which look like build labels are normalised. For example: plz query config plugin.go.pleasegotool outputs ///go//tools:please_go instead of //tools:please_go which was what was actually specified by the go plugin. This allows consumers of the values to not care were they came from (if they want to build the target for example).

[marcuscaisey]

Thanks for having a look at that build failure pebers, I missed that 🤦‍♂️

I don't really understand the cause (maybe the build.xattrs = false in the linux-build-alt .plzconfig?) but I can believe that your change will avoid it and it makes sense anyway since the test doesn't actually need the thing the label points to to exist.

Now the failure we're hitting in the build-darwin job is the race detector sounding the alarm (different from #3556). Seems unrelated to my change though since I see the same failure on my arm mac on master (also building plz wouldnt go through the code path i changed). I ran the pipeline myself and all of the jobs passed.

[peterebden]

Okay took a while but I think that failure is fixed now. Have rebased this and hopefully this time it should work 🤞