search

facebook / buck2

Build system, successor to Buck
https://buck2.build/
Apache License 2.0
3.59k stars 224 forks source link

Buck1 compatibility flag #456

Open benbrittain opened 1 year ago

benbrittain commented 1 year ago

There are a few places where design decisions for buck2 were made based upon the need for (primarily) Meta to maintain buck1 backwards compatibility. Most open source users don't have this need and it is more of a potential problem than a useful feature. It would be nice if buck2 could throw a warning or error when these apis/patterns are used.

thoughtpolice commented 1 year ago

Curious, what things/choices are you thinking of? The Prelude and its APIs, or the core design decisions for Buck2 itself? UX concerns? FWIW, as someone writing their own Prelude from scratch, I really haven't found too many unfortunate design decisions as far as the core system goes. Though, some things are obviously intentional choices that have no clear correct answers for all users (tests aren't cached, but I want them cached), some features not completely done yet (configuration modifiers & configuration design), and some components need more polish and love (a lot of RE performance and polish, tracing/log UX, etc.)

There are some UX concerns I have but I'm not sure how much they matter in the limit. For example, I continue to find mystery meat .buckconfig options to control various behaviors. It just isn't discoverable at all, its design is constrained by buck1 usage and having to share between the two. A .buck2config configuration (and a requirement that the two configuration files are mutually exclusive) that had a more thoughtful design and implementation would be very welcome, i.e. every option was instead described declaratively in a single location and had to have a description of what it did. But not revolutionary, and I can live with the existing choices.

The prelude is another matter entirely, of course. There're a raft of Starlark API choices and toolchain design decisions that don't necessarily map well onto non-Meta users, at least not without a lot of background motivation and jumps of faith for certain things. I also have other related questions like "Will we ever be allowed to use non-standard Starlark extensions that exist in starlark-rust in our BUILD files?" I could probably think up more if I tried, but those are some examples.

benbrittain commented 1 year ago

The example which started this idea was us talking about compatible_with vs target_compatible_with. compatible_with really is an odd API (or vs and) and probably should not be used by any new buck2 code, but is very easy for users to accidentally use.

ndmitchell commented 1 year ago

CC @cjhopman who probably has a good idea about compatible_with and the long term plans.

There are lots of things we'd like the rules to do that are currently handled in macros inside Meta. Those will evolve over time, probably more rapidly once Buck1 dies.

As for actual features, there are a small number that are guarded behind soft_error!. Internally these report usage via telemetry. But with open source we just fail with an error. So in some cases we do make open source more restrictive.