Skip to content

Output default values for plugin config fields from plz query config - #3529

Open
marcuscaisey wants to merge 2 commits into
thought-machine:masterfrom
marcuscaisey:config-plugin-default-value
Open

Output default values for plugin config fields from plz query config#3529
marcuscaisey wants to merge 2 commits into
thought-machine:masterfrom
marcuscaisey:config-plugin-default-value

Conversation

@marcuscaisey

Copy link
Copy Markdown
Contributor

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).

@peterebden
peterebden force-pushed the config-plugin-default-value branch from 857c8ae to b0c42df Compare August 29, 2026 07:25
@marcuscaisey

marcuscaisey commented Aug 30, 2026

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants