[zhengyi13]

Probably not in the way that you might mean it, but for me (Xoogler, 2010 - 2023) internalizing bazel means:

"Hey, where's your tool's code in $MONOREPO?" "<path/to/stuff>"

Cool:

    g4d my-citc-client # moral equivalent to `cd ~/repos/stuff`
    blaze run path/to/stuff:target

... and you get a running version of whatever $stuff is, immediately built from head, quickly - no matter the set of dependencies, or which language they were built in. I can just try your thing out immediately with a common interface for all the builds, and I don't need to understand the build at all, unless or until I do, and then OK, absolutely every single build is always expressed in exactly the same way, same idioms, same patterns...

[derriz]

Probably it's just down to a different understanding of the word "internalize".

I know how to _use_ bazel effectively to do my work. I'm comfortable with its well-designed surface but whenever I've tried to understand the inner machinery I've given up - especially when presented with a bunch of custom skylark rules code.

It's like an anti-git in some regards - the surface of git (the CLI) is an abomination in many ways but the the mechanics of the tool are so ingrained and the model is so clear and simple - I never feel uncomfortable.

I've a need to have some comprehension of the inner machinery or the underlying model of my tools.

[trashburger]

I've personally driven adoption of Bazel across two teams in our company over the last two years (we have an extremely fragmented set of repos that touches everything from hardware, to end-to-end simulation, to cloud software, to CDK stacks that deploy the software). There are still some aspects (ha) that confuse me like transitions, exec groups and constraints, but most of the time it's all about building a graph of actions (command executions) by executing code, and hooking up external dependencies into the graph inputs. Mind telling what confuses you in particular? Maybe I can be of help somehow.