Please build is really fantastic and I loved using it. If it had better ide integrations I'd recommend it over bazel for oss work. It's extremely fast and we'll documented and the community seems very welcoming.<p>Glad it's getting some discussion on HN. Can't wait to hear other's experiences.
I love build tools, and work with them professionally, and this tool seems to be getting one thing quite right: it is not injecting itself into the dependency resolution process. Where I see build tooling fall down is where they try to replace the idiomatic dependency modeling tools that exist in each language.<p>The build logic and CLI experience looks to be well thought out. I really like the native sandboxing support and the intentional exclusion of the calling environment. There's a lot of polish here.
It's hard to tell what the value proposition is here, apart from vague hand-waving about parallelization. The quick start is not enough to get started actually building something.<p>Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.
How easy is it to "port" BUILD files between the various open implementations (Bazel, Buck, Pants, Please)? If you have a project someone else wrote with the intention of using it in e.g. Bazel, can you integrate it into your Please build system, or would you need to treat it as an opaque build process (same as if you were shelling out to ./configure && make)?<p>As a concrete example, one frustration at $DAYJOB is that building certain Google-released OSS is hard to integrate with our existing build system because Bazel is pretty opinionated about compiler-provided headers, output paths, etc. We're calling Bazel as a subprocess during our build and making various files available to it to make our compiler build visible to it, and then we pack up the results. I'm pretty sure if we somehow adopted Bazel for our entire build this would be much better - would it also be better if we adopted one of those other systems?<p>(Maybe one way of asking this is, are any of the corporate sponsors of Buck, Pants, or Please building third-party Bazel code from source? Or vice versa?)<p>A broader question: would it be worth defining a compatible <i>subset</i> of BUILD file syntax and library calls (i.e., not just Starlark but also the rules themselves for common things like building C libraries or JARs)?<p>Are we in the build-system equivalent of the vendor-specific C / C++ / UNIX implementations, and will a cross-vendor standardization effort emerge one day?
They make some lofty claims about Python packaging, has anyone used this tool in a reasonably high stakes environment for Python? How was the experience?
I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?
I can imagine a project that successfully replicates the entire google developer environment (distributed build system w/ caching, monorepo with presubmit checks, code review, testing, etc) would be successful since ex-googlers would be likely to advocate for it inside their own organizations and most orgs don't have the engineering time to build all this themselves.<p>Without this tooling large organizations tend to silo which creates high engineering costs (every project starts from scratch, no shared frameworks/libraries, no standardizing around best practices, etc).
First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I thought, why not simply avoid their published mistakes without changing build systems? I learned everything I could about make, discovered that variables are secretly lambdas, and that enabled me to figure out a way to have a static archive package for each folder, which also avoided the need to write a makefile code generator. Then I wrote a simple C program to check incremental elf symbols so the build graph stays sanely formed. It totally got make working like a dream in a way I simply hadn't seen before. <a href="https://github.com/jart/cosmopolitan/blob/master/tool/build/package.c" rel="nofollow">https://github.com/jart/cosmopolitan/blob/master/tool/build/...</a>
I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python.<p>The value proposition is also a bit more clearly defined there [2]<p>[1]: <a href="https://www.pantsbuild.org/docs/welcome-to-pants" rel="nofollow">https://www.pantsbuild.org/docs/welcome-to-pants</a><p>[2]: <a href="https://www.pantsbuild.org/docs/how-does-pants-work" rel="nofollow">https://www.pantsbuild.org/docs/how-does-pants-work</a>
Why are landing pages so incredibly uninformative?<p>In practice, I spend under two minutes to click around and see if can 'get' it. What does it do especially well? What's the syntax look like? If you are brave, what doesn't work well?<p>No idea why this exists or why I would use it. Bad website. No cookie.
Admitting ignorance here, I have never intentionally used a build system like this. My normal process for e.g. Python deployment is to write a Dockerfile that installs the dependencies, installs packages, and then copies my user code in. Then I use Pulumi to upload that image to a Docker repository & deploy it to a k8s instance.<p>What am I missing by doing that? This <i>looks</i> really slick, but I'm not sure how, why, or where to use it.
> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar<p>Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?
At some point it becomes actively harmful to build and publicize tools that further the fragmentation of an ecosystem. We need a unified build system, not yet another build system. To get there we have to contribute to existing tools to keep making them better.
I like the idea of please.build. But I'd like it more if it used Starlark :-(<p><a href="https://github.com/thought-machine/please/issues?q=is%3Aissue+skylark" rel="nofollow">https://github.com/thought-machine/please/issues?q=is%3Aissu...</a>
<a href="https://github.com/thought-machine/please/issues?q=is%3Aissue+starlark" rel="nofollow">https://github.com/thought-machine/please/issues?q=is%3Aissu...</a>
If I was building a company today I would use Earthly instead of Buck, Bazel or Please. I think Earthly gets out of the way of actually low-level builds and instead focusing on high-level, Dockerised targets. The benefits range from allowing proper IDE support, to very easy system/integration tests, while still reaping the benefit of remote execution and aggressive caching.
Hey guys! Thanks for checking Please out! I see a lot of recurring themes in the comments so I thought I would clear some things up.<p>What is Please?<p>Please is a multi-language build system designed for huge mono-repos. It was created by a couple frustrated ex-googlers who were familiar with Blaze (which was later open sourced as Bazel). We found the "real world" alternatives to be somewhat lacking and so Please was born!<p>Please draws inspiration on the Blaze paradigm. If you're familiar with Bazel, the biggest difference is Please aims to be simpler and have far less magic in the binary. We push the implementation of the build rules into the build language, dog feeding them to ensure Please is flexible enough for any task. Also Please is written in Go so doesn't require a JVM ;)<p>If you're not familiar with Blaze/Bazel, here's what all the fuss is about:<p>1) Hermetic builds: builds are run in their own tightly controlled environment. Each step of the build runs in their own temp directory isolating them from other steps and only having access to the files and environment variables they've declared as their inputs. Please also has sandboxing built in taking advantage of the linux kernel to further isolate tests.<p>2) Scalability through incrementallity: if you've used Make, you're probably familiar with caching problems. Make uses last modified timestamps on files to determine if they need to rebuild each step, which turns out is fallible. Please uses a hash based approach which is far more robust. Most of our developers don't even know how to clean the cache. As a result, we can incrementality build our entire repository locally and on our CI workers no matter how big our repo gets.<p>3) Flexibility: the build language is a dialect of python. This can be used to write "build definitions" which define a unit of work i.e. compiling a Go package. There's nothing special about the built in definitions; it's totally possible to write your own to automate nearly any part of your development process. You could generate code, template kubernetes .yamls and beyond!<p>4) Unified developer experience: The please command line provides a unified experience across your codebase. Want to test all the tests under a branch of your repo? `plz test //some/part/of/the/repo/...`. It doesn't matter what language you're using, what those tests depend on etc. etc. Please can always run them for you.<p>PS: Apologies for the website. We're a small team of build system engineers, not front end types. If you want to offer your skills, I'd be happy to point you in the right direction: <a href="https://github.com/thought-machine/please" rel="nofollow">https://github.com/thought-machine/please</a>.
Have used it in a go mono-repo. It’s own convention on packages and bad integration with IDE makes it a hard sell for me. I mean I just paid for Goland IDE why would I waste my time integrating with something that might or might not work for others. It’s a very hard sell.
I prefer xmake<p><a href="https://github.com/xmake-io/xmake" rel="nofollow">https://github.com/xmake-io/xmake</a>
Does Please allow one to easily specify a specific JDK version to use to build and run tests?<p>I wasted a lot of time getting Bazel to use a modern JDK.
I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python.
We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human".<p>When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast written codebase and disregard for proper, complete documentation.
"Because you can just read and understand the code", yeah I can do the same in well maintained code of a faster language.