Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please – A cross-language build system

please.build

Post reply on HN
Print view View original

251–257 of 257 posts

Re: Please – A cross-language build system

#251

Post by rhencke »

tomlu wrote: post #248
rhencke wrote: post #178

Earlier quoted context omitted.

Unfortunately, reality is messier than this. For example, Please currently has escape hatches that can be used that nullify these guarantees. What I have found is that if such a mechanism exists it will eventually be abused. My perspective here is specifically from that of a maintainer of large builds where the code base is always under active development. Murphy's law becomes your enemy at scale. This is not a criti…

I haven't had many issues with non-determinism when using Bazel/Blaze? Especially when you use remote execution or sandboxing it's pretty hard to avoid being hermetic.

Here's what I mean:

    genrule(name = "oops", cmd = "date > $@", outs = ["oops.txt"])
This is admittedly contrived, but sadly not unrealistic.

Again, I am not picking on Bazel here. Correct builds are difficult enough to get right even when everyone involved wants to keep the build correct! But, the reality is that a lot of real-world build conditions can be downright hostile. (did you know that ext4 vs xfs can change the order JARs in the same directory are loaded off the classpath? I wish I didn't!)

Re: Please – A cross-language build system

#252

Post by lvh »

laurentlb wrote: post #227
lvh wrote: post #130

Earlier quoted context omitted.

But Bazel is developed by Google itself right now. Presumably if you missed Google tooling you'd rather use Bazel, no? I'm not suggesting Bazel is perfect: I think e.g. Starlark's insistence on being a separate language does more harm than good. (FWIW I also think the JVM objection is a little silly.) But I am saying preferring the Google tooling would ostensibly mean you like Bazel a lot already :)

What do you mean with "insistence on being a separate language"? Many build tools have their own DSL.

Starlark is _almost_, but not quite_ Python, and Python 2 at that. You could do everything Starlark does in actual Python and get stuff like static type checking for free.

I think the term DSL is overloaded here? Consider all the Lisp and Ruby stuff that's definitely DSL but doesn't need most of a language implementation.

Re: Please – A cross-language build system

#254

Post by IggleSniggle »

megous wrote: post #250
IggleSniggle wrote: post #245

Earlier quoted context omitted.

It’s not really intended as a defense against being owned per se, it’s more about knowing what’s going on and getting an additional signal about the risk profile (not just from maliciousness) of the thing I’m about to run. That said, I generally pipe to file and cat the file, yes, if only because it somehow feels wrong to download it twice.

I understand, but cating the saved file or printing from pipe to the terminal directly has identical issues. Terminal ANSI escape sequences are interpreted either way.

Great point. Thank you.

Re: Please – A cross-language build system

#255

Post by dblotsky »

jrockway wrote: post #241
dblotsky wrote: post #219

Earlier quoted context omitted.

I am personally not convinced that any build system can be correct and general, but perhaps that’s my lack of experience speaking. On that 30 minute note though: so, how big does the project need to be in order for Make not to be enough? And at that size, why wouldn’t the project invest the extra week it takes to get the Makefile correct?

I completely agree with you. To give the build system the understanding it needs, you have to give up the generality. For me, I've found that the results are best when you use a build system and you use it exactly the way the author intends. For example, Go's built-in build system is so good that you don't even notice it's there. It automatically updates its configuration as you write code. It does a perfect incremen…

Yeah, that tradeoff between generality and correctness really seems tyrannical.

It kind of feels like the best trajectory is to start small with a general build system, and upgrade as needed? And then if you are confident the project will grow, starting with the specific build system fine too.

Re: Please – A cross-language build system

#256

Post by JensRantil »

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.

Re: Please – A cross-language build system

#257

Post by tomlu »

rhencke wrote: post #251
tomlu wrote: post #248

Earlier quoted context omitted.

I haven't had many issues with non-determinism when using Bazel/Blaze? Especially when you use remote execution or sandboxing it's pretty hard to avoid being hermetic.

Here's what I mean: genrule(name = "oops", cmd = "date > $@", outs = ["oops.txt"]) This is admittedly contrived, but sadly not unrealistic. Again, I am not picking on Bazel here. Correct builds are difficult enough to get right even when everyone involved wants to keep the build correct! But, the reality is that a lot of real-world build conditions can be downright hostile. (did you know that ext4 vs xfs can change t…

Yeah fair point. At Google a lot of these non-deterministic rules are either banned through "date" just not existing on remote execution machines, or through determinism tests that ensure rules behave. Maybe in real-life scenarios it's not as easy as I claim, as you suggest.
Post reply on HN