Live data from Hacker News

Please – A cross-language build system

please.build

61–70 of 257 posts

Re: Please – A cross-language build system

#61

Earlier quoted context omitted.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

Thanks for all the hard work! I'm very excited to see where this goes. Have you considered sponsoring, or accepting donations, to work on IDE integration? That's pretty much the only reason I migrated my current employers codebase over to Bazel instead of Please.

As a big fan of Bazel (ok, Blaze), I'm curious what's different than what Blaze offers

Re: Please – A cross-language build system

#62
post #11

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. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

Thank you for making this!

My rubric for documentation is "how many clicks to code". I found the installation instructions, and started to look for usage, but didn't find it. Too many clicks. That's where I'd start.

PS - IMO the gold standard for this evaluation method is Sinatra.rb, which is zero clicks to code.

Re: Please – A cross-language build system

#63
I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python.

The value proposition is also a bit more clearly defined there [2]

[1]: https://www.pantsbuild.org/docs/welcome-to-pants

[2]: https://www.pantsbuild.org/docs/how-does-pants-work

Re: Please – A cross-language build system

#64

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. Without this tooling large organizations tend to s…

A surprisingly hard sell even if your organization has a supermajority of ex-Googlers. There's a really strong meme out there that if you are smaller than Google, which is almost universally true, then you shouldn't adopt their practices even when they are zero-cost and obviously superior.

Re: Please – A cross-language build system

#65

I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python. The value proposition is also a bit more clearly defined there [2] [1]: https://www.pantsbuild.org/docs/welcome-to-pants [2]: https://www.pantsbuild.org/docs/how-does-pants-work

Hey, Please maintainer here! One of the big differences to the other Blaze like build systems is Please actually doesn't treat any of the built in languages any differently to other languages. They are implemented entirely in the build language which is totally open to you as a consumer of Please.

Another big difference is Please is written in Go so there's no dependency on VMs or runtimes.

Re: Please – A cross-language build system

#66
post #40
post #7

Earlier quoted context omitted.

I don’t think this is a fair reason to write the tool off. They support Homebrew, and I’m sure will add other install methods in the future. Piping to bash is no worse than clicking “yes” on every step of an install wizard.

The alternative is not “install wizard”, it is either “here is a deb file with no post* scripts” or “here is a tar.gz, extract it anywhere and add symlink” Both of those are vastly safer, because they do not require root privileges, and guarantee to uninstall cleanly.

This. Simply the decision to eschew standard package management already says unpleasant things about their approach to integrating with my environment, or in whatever it is the installation does being reversible using standard tools. "Install wizards" do indeed have exactly the same issue, which is why those are also terrible.

Re: Please – A cross-language build system

#67
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?

Re: Please – A cross-language build system

#68
post #11

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. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

As someone who has had to run and maintain build systems for several (sadly far too) large projects (5MLoc+), I want a product that sells me on how easy it is to create _correct_ builds, and how impossible it is to create incorrect ones.

So much wasted time goes into diagnosis of incorrect results from incremental builds that most people who implement CI systems never use incremental builds, and always build from scratch. Developers are far too used to having to do things like 'make clean' because their build didn't work quite right. Efficiencies are then gained by doing things like ccache/Gradle build cache, which trace their dependencies better than most naively written build systems do.

Edit: zig is a beautiful exception (https://ziglang.org/download/0.3.0/release-notes.html#cachin...)

Re: Please – A cross-language build system

#69

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?

Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools.

If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical.

disclaimer: have not used these particular tools, but the domain is nice and polite

Post reply on HN