top | item 44114396

(no title)

chrismatic | 9 months ago

The point about trying to stick with a single language build tooling really cannot be stressed enough. It is what prompted me to write a simplified version of Bazel, a generic "target determinator" with caching capabilities if you will. I call it "Grog", the monorepo build tool for the grug-brained developer.

https://grog.build/why-grog/

discuss

order

oftenwrong|9 months ago

I am excited to learn of this project. I started working on something quite similar recently. It's a surprisingly unaddressed niche.

One thing your tool appears to be missing (IMO) is execution sandboxing. This is useful, as you likely know, for avoiding undeclared dependencies and for avoiding dirty builds due to actions polluting the source directory, among other things. I was playing around with allowing configurable sandboxing, with symlink forest and docker as two intial options.

chrismatic|9 months ago

I fully agree. I was also thinking about docker or symlinks, but it seemed hard to design the API without any actual user feedback. Pants environments [0] look interesting.

Very cool that you are also recognizing this issue and working on it. I sent you an email in case you want to exchange further.

[0] https://www.pantsbuild.org/stable/docs/introduction/welcome-...

bluGill|9 months ago

If a single language is an option you are a small project that is not facing the problems people on large projects are facing. A monorepo will be easy for you without read the article and the lessons learned.

Come back when you have millions of lines of code, written over decades by hundreds (or thousands) of full time developers.

dezgeg|9 months ago

What a weird take, "millions of lines of code, written over decades" applies to quite many C (or C++) codebases where using a high-level language is not a possibility (and companies that do have such codebases are pretty conservative and don't even talk about Rust no matter how great fit it would be).

chrismatic|9 months ago

There is a space between the two types of repositories you are describing. One where you just have enough tools/langs that a single-language setup does not cut it for you anymore, but investing all that effort into Bazel does not seem worth it yet. That is the gap that Grog is meant to fill.