Buck2 2025 Q2 Plans

[alexlian]

Preface

The format is a work-in-progress, and the content beyond the buck2 tool itself is sparse as the adjacent tools and prelude work is dispersed across a number of teams within Meta and we have not thoroughly surveyed and collected information from them along with their plans may be more fluid.

As for the buck2 tool itself, we are still building our muscle of planning features, as we’ve come off a number of years just working to migrate internally away from buck1. We welcome feedback on the format and how the information is presented.

Meta Buck2 2025 Q2 Plans

2025 Q1 (past)

• Internal rules cleanup of buckconfigs enabling better configuration modifiers use and eliminating modefile switch costs. This steps us incrementally closer to align internal and external preludes.
• Documentation
• Configuration Trimming / Action Deduplication further exploration ( Share work across configurations by setting working directory for actions then canonicalizing that working directory in RE #611 )
• BXL Streaming RFC implemented
• sqlite materializer state and hash all commands are enabled by default now for open source
• Prelude
  • Migrate to Go 1.20 test runner and coverage collector

2025 Q2 (looking forward)

• Continued rules cleanup (see above)
• Structured Action Errors
  • Ability for rule authors to receive the output of failed actions and categorize errors and pass them back to other tooling in a structured format
• Further improve our Open Source processes
• Execution groups
  • A new API that enables the definition of actions with distinct execution platforms within the same target.

Future (No defined timeline)

• TestInfo v2
  • Decoupling test listing and execution logic from the test runner by utilizing Starlark definitions. This approach would help reduce discrepancies in how tests are managed between internal and external versions of Buck2.
• Go
  • Reimplement go:embed using native buck API
  • Migrate to the new dynamic value buck API
  • Improve OSS toolchain
  • Add more examples for OSS users
  • Open-source Buck2 GoPackagesDriver for LSP/Linter integration
  • Build Go stdlib natively with buck (instead of using go build)

[zjturner]

Thank you for this! Few questions / comments:

Internal rules cleanup of buckconfigs enabling better configuration modifiers use and eliminating modefile switch costs. This steps us incrementally closer to align internal and external preludes.

Are there any plans to ever drop support for modefiles and make configuration modifiers The Only Way?

Configuration Trimming / Action Deduplication further exploration ( #611 )

🙏 huge thanks for prioritizing this

Structured Action Errors

Not exactly related to Structured Action Errors, but just error handling in general. Many, many, many analysis errors do not report a BUCK / bzl file and line number where the error occurred. Could this happen?

[scottcao]

Are there any plans to ever drop support for modefiles and make configuration modifiers The Only Way?

We will continue to work towards enabling more behavior via modifiers but I think it's unlikely that we will drop support for buckconfigs/--config flags. The cost to doing this is quite high and it's hard to justify doing a big migration like that at the moment.

[zjturner]

Thanks for bringing this up! Can you provide an example and potentially the behavior you are hoping for? I can think of a couple of errors (Dependency chain and target incompatible errors for example) that fit this description, but it's totally possible that I'm missing something more obvious. Line number for the 2 I mentioned could be tricky, but reporting the file can definitely happen. However, the error messages should already report the target with the failure, I want to better understand the advantages of reporting the BUCK files over targets. Thanks!

I don't have an example ready off the top of my head, but the next time I encounter one I'll post it to this thread.

[zjturner]

Here's an example:

BUILD FAILED
Error running analysis for `root//Client/WindowsClient:WindowsClient (internal//platforms/target:windows-x86_64#b9ec767197ea90c5)`

Caused by:
    0: Error looking up configured node root//Client/WindowsClient:WindowsClient (internal//platforms/target:windows-x86_64#b9ec767197ea90c5)
    1: Error resolving configuration deps of `root//Client/WindowsClient:WindowsClient (internal//platforms/target:windows-x86_64#b9ec767197ea90c5)`
    2: Error getting configuration node of `prelude//os:iphoneos` within the `internal//platforms/target:windows-x86_64#b9ec767197ea90c5` configuration
    3: Error running analysis for `prelude//os:iphoneos (<unbound>)`
    4: Error looking up configured node prelude//os:iphoneos (<unbound>)
    5: looking up unconfigured target node `prelude//os:iphoneos`
    6: Unknown target `iphoneos` from package `prelude//os`.
       Did you mean one of the 21 targets in prelude//os:BUCK?
       Maybe you meant one of these similar targets?
         prelude//os:ios
         prelude//os:illumos
         prelude//os:none

The actual usage of prelude//os:iphoneos is not in the definition of any of the targets printed anywhere in this error message.

[Will-MingLun-Li]

Ah I see, ya this is the type of errors I had in mind and also falls into the error buckets that I mentioned in before. I definitely agree that we should be adding some more context in these error message. Reporting the file or adding some more useful information shouldn't be too difficult, but line number might be tricky. I have a task in my backlog to surface some more error information for another tool that's somewhat similar to this, so I can take a look once I finally get to that

[zjturner]

In this case, even just mentioning the offending target would be helpful :) But combination of filename + target would be even better.

[sluongng]

Configuration Trimming / Action Deduplication further exploration

FWIW, this is an issue in Bazel as well. By default, the output path will come with a prefix of the configuration hash, that way, similar actions with different configurations will result in separate outputs.

There is a recent experimental feature called "path mapping" (bazelbuild/bazel#22658), toggled with https://bazel.build/reference/command-line-reference#flag--experimental_output_paths, which let rule authors opt-in to strip out the configuration prefix. Example: bazel-contrib/rules_go@6f206ad

IIRC, currently if stripped, Bazel would still produce multiple duplicated actions and rely on the RBE scheduler to deduplicate the execution of these identical actions.