This was one of my bigger pain points with Nix as well: there was a lot of "reinventing the world" just to avoid network access. With Brioche, I stuck with disa

This was one of my bigger pain points with Nix as well: there was a lot of "reinventing the world" just to avoid network access. With Brioche, I stuck with disabling network access by default, but there's an escape hatch to specifically opt-in to networking (by calling `.unsafe({ networking: true })` on a process recipe). My thoughts are that Cargo, NPM, Poetry, etc. have all done a great job building amazing tooling to download and verify resources from the network against a lockfile, and I wanted to be able to leverage as much of that as possible. So, for example, `npm clean-install` will give you more-or-less the same guarantees that Nix does, so my thought was as long as it's encapsulated properly, I'd rather lean on existing tooling (that's also why I used the term "unsafe", you need to make sure you only access the network with tools that do sufficient verification!) I've generally stayed away from using the term "reproducible build" when talking about Brioche, because I don't feel like it fits the reproducible-builds.org definition (though I don't think Nix does either). But, if a build is cached locally or in the registry, then you're guaranteed to get the same result, since it'll just re-use the cache The sandboxing also gives pretty strong guarantees around hermetic builds[1]. So I think you could do reproducible builds _within_ Brioche (and I'd like to add tools to make this even easier), but I'd say Brioche itself doesn't give you reproducible builds out of the box [1]: https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity