- integrations
- Bazel
- Concepts
- How rules_ocx works
How rules_ocx works
rules_ocx deliberately never re-implements OCX internals in Starlark.
All resolution goes through the ocx binary.
The durable contracts are the ocx.lock digests and the OCI manifests.
Why shell out to ocx
Section titled “Why shell out to ocx”OCI protocol, registry auth and the store layout belong to OCX. If rules_ocx copied them, every OCX change would need a matching Starlark change. A missing capability becomes an issue against ocx-sh/ocx, not a workaround in this module.
The four steps
Section titled “The four steps”- The
ocxextension creates@ocx_toolby downloading the pinnedocxrelease listed in the vendoreddist/dist.jsonsnapshot ofhttps://setup.ocx.sh/dist.json. The download is sha256-verified. - The
ocx.projectandocx.packagerepository rules run that binary. They callocx lock --checkas the staleness gate,ocx pullorocx package installto fill the store, andocx --format json env --pinnedfor the composed environment. - Packages live in the shared
OCX_HOMEstore,~/.ocxby default. It is content-addressed, digest-pinned and hardlink-composed. - Each generated repository contains launcher scripts that apply the package environment and run the store binaries. They work in
tools =, in$(location ...), insh_testenvand withbazel run.
What is shared
Section titled “What is shared”Repository rules run unsandboxed, so the store is shared with your shell and with CI.
A package is fetched once per machine.
Launchers therefore reference absolute store paths, as nixpkgs does. Remote execution is a non-goal at 0.5.0.
isolated_home = True keeps one store per repository, at the cost of a full re-download.
Hermetic in which sense
Section titled “Hermetic in which sense”Bazel’s hermeticity guide names the benefit: tool versions that no host install can change.
rules_ocx gets there through digests in the lock file, not through a sandbox. A tool pinned this way gives the same bytes on every machine, which is what keeps cache hits stable.
Related pages
Section titled “Related pages”- Trust and config explains who decides what a fetch may accept.
- Share one toolchain puts this into practice.