1. @bazelbuild is IMO the best choice for a build system if you a very large codebase you want to build entirely from source, or even if you don't have a large codebase but you have many different languages (some Go, some Java, some Python, some C, some C++, some ....)
-
Show this thread
-
2. There are many downsides to using Bazel, and those can be summarized around a few problems: Google owns development and external contributors are 2nd (or 3rd) class citizens. A high churn rate: you deal with constant deprecations/breakages/redesigns. Ergonomics are at best ok.
1 reply 0 retweets 14 likesShow this thread -
3. So why write a new build system? My main motivation is to explore key design elements from Bazel in a simpler setting with the aim to make them better known and more widely applied. The build problem (more generally processing DAGs of tasks) is very general yet ignored by many
1 reply 0 retweets 11 likesShow this thread -
4. So, I'm doing a few things: first, use a typed language to describe builds. We have a Build[A] type that is sort of like a Future but for builds. If we are forced to write types on all our builds a lot of bazel's magic (and difficulties) evaporate.
2 replies 0 retweets 11 likesShow this thread -
5. Bazel tries to elide when you are dealing with a Record, a Build[Record], a string that is a path, or a string that is a label for a build output. This confusion makes it challenging to write complex plugins for bazel which must be done in an untyped python subset language.
4 replies 0 retweets 8 likesShow this thread -
6. In Bazel all tools are native binaries, but we also want total reproducibility, so setting up toolchains (e.g. c compilers) is a big pain and a source of non-reproducibility. My system makes all tools jars, and builds jars, so the problem is FAR simpler and easily explained.
2 replies 0 retweets 8 likesShow this thread -
7. Bazel is more similar to Make than to Maven: it basically understands nothing of external packages. Modern build tools generally conflate package management with build. Due to bazel's static graph API, writing hermetic package management in bazel is a serious challenge.
1 reply 0 retweets 10 likesShow this thread -
8. By assuming you are on the JVM, you can make fetching maven/ivy artifacts first class. It makes the model a bit less general, but in practice MUCH more easily usable.
2 replies 0 retweets 3 likesShow this thread -
9. Bazel should add more ease to making hermetic repo rules, the only rules that can do network access. Unfortunately, the obvious approach requires dynamic graphs, which the bazel developers are loathe to expose to users. Without that, repo-rules have to fetch magic binary tools
3 replies 0 retweets 4 likesShow this thread -
10. My real interest is a data-artifact build system: today's artifacts depend on yesterday's artifacts plus the events that just came in. A principled system like Bazel (your build as a pure function) plus a time-axis could represent a real advance for data workflow systems.
7 replies 0 retweets 26 likesShow this thread
sounds really close to my white whale of a not-airflow data workflow system!
-
-
I was about to send this your way and then I saw your toot
1 reply 0 retweets 2 likes -
long toot
0 replies 0 retweets 3 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.