Project

Buckaroo

A decentralised package manager for Buck and Bazel projects, written in F# and winner of the 2019 F# open-source challenge, that resolves dependencies directly from source control using conflict-driven clause learning.

F#BuckBazelGit
GitHub →

Buckaroo is a decentralised package manager for Buck and Bazel projects, written in F#. It won the F# open-source challenge in 2019. It was marketed primarily as a C++ package manager because that's where the need was greatest — C++ build tooling is notoriously chaotic and unstandardised. Projects routinely reinvent the wheel or vendor and patch dependencies just to make them compile, because there is no agreed-upon package manager and most build systems were not designed for distributed building or caching. Buck and Bazel are the exceptions — both were engineered for reproducibility and remote caching — which is why Buckaroo targeted them. Buckaroo was originally built to support an internal C++ JIT that required building everything from source for optimal performance. It was later proposed as a general solution for the C++ ecosystem, but adoption never took off: the cost of switching build systems was too high for most projects. Instead of relying on a central registry, packages live directly in Git — GitHub or any hosted endpoint. There is no publish step.

Buckaroo in action

Quick Start

buckaroo init
buckaroo add github.com/buckaroo-pm/boost-thread@branch=master
buck run :my-app

Key Features

  • Decentralised — no central registry; packages are sourced directly from Git
  • Reproducible builds — every resolution is fully deterministic and lockable
  • Live at head — depend on a Git branch, not just a tagged version
  • Private dependencies — avoid diamond-dependency hell by isolating transitive deps
  • Semantic versioning — standard semver constraints supported
  • Buck & Bazel native — generates BUCK/BUILD files automatically; works with both build systems

Conflict-Driven Dependency Resolution

Dependency resolution is a constraint-satisfaction problem equivalent to boolean satisfiability (SAT) — NP-complete in the general case. Buckaroo makes it harder: manifests live in Git history, so the full constraint graph can only be revealed by fetching packages on demand.

Buckaroo's resolver borrows Conflict-Driven Clause Learning (CDCL) from the SAT-solving world. When a contradiction is found — say, two packages require incompatible versions of a third — the resolver records the unsatisfiable core: the minimal set of clauses that caused the conflict. Any future search path that would re-introduce the same combination is pruned immediately, with no further network calls.

Two additional optimisations compound the gains:

  • Conflict-first ordering — constraints most likely to fail (e.g. pinned versions) are explored first, maximising early pruning
  • Manifest deduplication — package versions with identical manifests are grouped so their sub-trees are only explored once

The result is a resolver that handles large, real-world C++ dependency graphs without the exponential blowup that plagues naïve backtracking approaches.

Why C++ Needs This

C++ build tooling is not standardised. Projects routinely reinvent infrastructure or vendor and patch dependencies to make them compile, because most build systems were not designed for reproducibility, distributed building, or caching. Buck and Bazel are the exceptions, which made them the right foundation for a serious package manager. Beyond that, there is no central metadata index — every manifest is a Git round-trip. In this environment, the CDCL-based resolver is not a micro-optimisation but what makes the tool usable at scale.

Buckaroo was originally built to support an internal C++ JIT that needed to compile everything from source for peak performance. It was later pitched as a general solution for the C++ ecosystem — but wide adoption never came. The cost of switching to Buck or Bazel was simply too high for most existing projects.

Related