I just recently came across the Please build system and was curious if any of the folks here had thoughts on it. https://please.build/

It looks like a playstation website.

That is not true. Brian Wickman wrote Pex back in 2010. I've been involved since the inception as a code reviewer and more recently as the primary maintainer.

@enough-analyst-54434 I thought @happy-kitchen-89482 wrote it because I saw a PR from him for pex integration with bazel

Nope.

I too would be interested to hear some field experts take on the build tooling scene. Perhaps not specifically wrgt please, but also bazel/buck/… etc. They all seem to promise pretty much the same stuff, and a quick read through of their resp. docs doesn’t really give much. I suppose one would have to try them out on a non-trivial project to really get a feel for their pros and cons. Hence my hope to get some insights, and save me the trouble (wouldn’t be going there any time soon, though, as I’d prefer to help fix pants if I find it lacking first..) 😉

We generally avoid making very direct comparisons to other scalable build tools, in part out of respect to the great work other communities are doing. It's true that there are lots of similarities, such as the remote execution API being standardized (a great thing!). Ultimately, we want people to have a delightful build experience, and if that happens through other build tools, that's a good outcome That being said, we believe a major differentiator with Pants is dependency inference https://blog.pantsbuild.org/dependency-inference/. Not only does it cut down on boilerplate, but also results in much finer grained cache keys. More generally, we're trying to hone in on removing the boilerplate traditionally involved with using scalable build tools, including 2.3's upcoming

tailor

goal to autogenerate BUILD files and @curved-television-6568 's PR to set a default module mapping :)

Thanks for the reply Eric, and indeed, I agree fully that we all benefit from each other, and all have strengths and weaknesses. Reducing boilerplate, and adhering to the DRY-principle is a dear goal of mine :)

Another differentiator might be that we put a lot of thought and design work into supporting Python as a first-class citizen and a driving use-case.