Hacker News new | ask | show | jobs
by danpalmer 730 days ago
It's a mess, yes, but it's better than most places I've seen that end up using a bunch of YAML/JSON and then poorly defined custom tools to mangle things together.

Also I'd argue that there's a good core in Google's config stack: everything resolving to a proto at the bottom, textproto for "raw" representations, and having one language above that. If we could standardise on that it would be good, but of course that's unlikely.

Does Boq use a subset of Starlark? I thought it was Piccolo. I've always assumed Piccolo predated Starlark and that Starlark was essentially the external-first rewrite with some learnings.
1 comments
laurentlb 730 days ago
From what I remember, Piccolo uses a Python interpreter.

Blaze also used to call a Python interpreter to evaluate BUILD files, but this is something I've changed. Starlark is unrelated to Piccolo, it started as an interpreter written inside Blaze. Starlark was created just before we open-sourced Bazel (because I didn't want to open-source the Python preprocessing).

Edit: indeed, Boq's manifest.bzl is Starlark.

link
esprehn 730 days ago
Boq has a lot of restrictions on what you can do (ex. No user functions except a tiny allow list they own). It lives in a manifest.bzl file though, and I'm pretty sure uses the golang starlark interpreter.
link
miki123211 730 days ago
> (because I didn't want to open-source the Python preprocessing).

Can you explain why?

I'm not trying to criticize anybody here, I'm just curious about the reasoning behind a decision to open source one but not the other.

link
laurentlb 730 days ago
It was a complete mess, hard to maintain the code, with scalability and performance problems. The semantics were very error-prone because it combined two interpreters (Python interpreter, optional, as a preprocessing step) followed by the interpreter in Bazel.

Bazel started a Python process for each BUILD file to preprocess. If two BUILD files were using the same bzl file, that bzl file would be parsed/evaluated twice. In a graph with lots of dependencies, it was causing a lot of redundant work. It's a bit like #include vs modules in C++: Starlark can evaluate a dependency file once, and provide the result for each BUILD file.

Python can be hard to sandbox, and we got multiple security reports about exploits.

Interestingly, Facebook Buck went through the same way. They originally copied the Python preprocessing approach. When we open-sourced Bazel, the Buck team took our Starlark (aka Skylark) interpreter, and started the migration. See https://buck.build/concept/skylark.html

link