Why hermetic matters
once, at 2 AM, a build failed on my machine for reasons the universe refused to explain. it passed on my teammate's laptop. it passed in ci. it failed for me. same commit, same code, same everything except whatever gremlin had moved into my `$HOME` without paying rent.
i did what any reasonable person does at that hour. no, not sleep. i went down a rabbit hole about ancient alchemists and never really came back. welcome to the rabbit hole, let me explain what i mean.
hermetic didn't start its life in a build system. it started with hermes trismegistus, a probably-fictional sage whom alchemists credited with the line "as above, so below." the alchemists would seal their flasks airtight so that nothing gets in and nothing gets out, and whatever transformation happened inside happened purely because of what they put in. they called it a hermetic seal. engineers, being professional word thieves, stole it three thousand years later for builds that behave exactly the same way.
and somewhere between the flask and the pipeline, i realised these patterns are secretly instructions for living a life. stay with me.
~ chapter 1: the seal
people hear "the build has no network access" and wince. limitation! cruelty! how will my dependency fetch itself! but a hermetic build isn't locked up. it's honest. it physically cannot sneak off to the internet at 3 AM and come back with some package nobody approved. every byte it consumes was written down somewhere, by someone, on purpose. if the build breaks, it breaks because of things i declared. that's not a cage. that's a contract.
in security we call this shrinking the attack surface. marcus aurelius, who never touched a terminal, called it the inner citadel: seal off your judgments from the things you can't control. the news feed is a network call. other people's opinions are transitive dependencies. the man was basically running a hermetic sandbox for his brain. inputs strictly declared, everything else dropped at the boundary. he would've loved bazel, and honestly bazel would've loved him back.
~ chapter 2: the rebuild
enter bazel, google's answer to a question that used to haunt big engineering orgs: if two people run the same build on the same commit, why do they get different binaries? bazel's answer is paranoia as a feature. pin every toolchain. hash every input. cache every artifact. run it on my dying laptop or a datacenter in singapore and you get the same bits back. bit. for. bit.
i've lost entire nights of my life to bugs that existed only on my machine. flaky tests that pass alone and fail together, like introverts forced into a group project. every single one was an unsealed flask. some hidden input nobody thought to declare. so we held a small funeral for "works on my machine" and nobody missed it. reproducibility was never about speed. it's the quiet confidence of being able to say: given these exact circumstances, this outcome was inevitable. try saying that about your tuesday.
~ chapter 3: the declaration
now meet starlark, the little language bazel files are written in. python's most disciplined cousin. no file i/o while evaluating. no randomness. no threads. you literally cannot be clever in it. you can only be clear. you say what you want and never how to get it, and the build graph stops being a procedure and becomes a fact.
this is where it stopped being about code for me. there's a line in the bhagavad gita about nishkama karma: act without attachment to the fruits of the action. do your duty, declare your intent, release your grip on the outcome. read that again. that's the most declarative sentence ever written, thousands of years before anyone needed a build tool to reinvent it: state the goal. surrender the execution. krishna wasn't talking about ci, but honestly, he could've been.
~ chapter 4: the rollback
if bazel hermeticises a project, nix hermeticises existence itself, which sounds dramatic until you watch it work. every package lives at a path hashed from its exact inputs. upgrade breaks your setup? roll the entire machine back like git checkout for reality. your os stops being twenty years of accumulated sediment and becomes a function you can evaluate again tomorrow and get today back.
when i moved my dotfiles over, the first thing i felt wasn't productivity. it was peace. nothing on my system is accidental anymore. everything that exists, exists because a file said it should. i don't know what the equivalent of that feeling is for normal people. winning the lottery, maybe. anyway, my desktop now has fewer surprises than my calendar, and i'm okay with that.
~ chapter 5: the leak
here's the part that keeps me up (past 2 AM, coffee number three, typical nerd you'd say but i'm okay with that). japan has this phrase, ichi-go ichi-e: "one time, one meeting." every tea ceremony, every conversation with a friend, happens exactly once and can never be reproduced. life is the one build that refuses to be hermetic. you cannot pin the inputs. you cannot re-run it. the environment drifts every second whether you declared it or not. people leave. you leave. the tea gets cold.
and somehow that's exactly why all these old practices exist. the stoics sealed their inputs. effort and judgment were theirs; reputation and outcomes were someone else's problem. karma yoga declared the action and let go of the result. the romans ran memento mori, which is just reading the build logs: every input is finite, the final seal closes on everyone, ship accordingly. even wabi-sabi, loving the cracked, unfinished thing, reads to me like making peace with a non-reproducible build instead of rage-quitting over it.
different cultures, thousands of years apart, no shared slack workspace, and they all arrived at the same design review: control what enters the vessel. be deliberate about what you declare. accept what comes out.
~ the end?
hermes had it right three thousand years before anyone drew a pipeline diagram. as above, so below: the sealed flask and the sealed self obey the same rule. the builds taught me the discipline. the philosophers taught me where to point it. the tea taught me that some things refuse to be rebuilt twice, and that's the whole point.
pin your inputs. release your outcomes.
it's 3 AM again and everything is green. goodnight.