📝 Team Buckaroo, 22/02/2019
💬 Discuss on Hacker News
There is a Medium post making the rounds at the moment about a dream C++ dependency manager. It's well written, and definitely worth a read: Accio Dependency Manager.
As you might imagine, we have spent a lot of time thinking about these issues. Package management is much harder in C++ than in other languages, and the design of Buckaroo went through quite a few iterations! Here's our take on the points discussed in "Accio Dependency Manager".
We agree! That's why packages in Buckaroo are one of two kinds:
Most Buckaroo packages use sem-ver, as you suggest. However, we think it is also important to be able to depend on versions that are not yet ready to be given a sem-ver. For this reason, packages can also depend directly on Git branches and tags. It is always clear what a version refers to because you can view it in Git.
The version DSL is described in our docs.
This is a big difference between Buckaroo and other package managers. We don't want to host your packages and we don't have to. This is because Buckaroo packages live directly in source-control, which is a piece of infrastructure your company already has.
Furthermore, after the packages have been resolved, we save the exact hashes of each. Future installations will use precisely the same versions you installed the first time.
We agree in principle, and Buckaroo is source-first.
But there is one big exception: proprietary packages that are only available in binary form. For these we support packages that download the binaries during the build process. The hash is locked-down and always verified.
Not when you use a build-system with hermetically sealed build-steps and network caching. This is the main reason that we use Buck for packages. CMake does not scale well here.
A package might be a signed tar-ball, but that is only half the story. We need to give packages sensible names, and that implies a registry of some kind. Buckaroo uses existing Git providers for these names.
OK, sure, GitHub is a single-point of failure. However, it is a single-point of failure that most developers already have. We think depending on GitHub (or BitBucket, or GitLab) is completely reasonable. For the paranoid, Buckaroo works equally well with a self-hosted Git instance.
We need a build-system.
To see why, consider what we need to be able to do to build each package:
If you have implemented all of these things, then... you have implemented a build-system. You might call this just a "wrapper" script that defers work to another build-system, but this is analagous to how CMake relies on Make. It's another layer of indirection.
Fixing C++ build-system fragmentation is a huge challenge. Luckily, the vast majority of builds are actually quite simple (Boost can be described entirely with globs, for example). We are going to open-source automated build-system transpilation tools in the very near future. Stay tuned!
And of course you can always call one build-system from other. It's hacky, but in a pinch it can work.
We have GitHub search, but Buckaroo could be improved in this aspect. More tools are coming!
We rely on GitHub, BitBucket and GitLab here. This is a reasonable trade-off given that people already depend on them. Self-hosted Git is fully supported. Buckaroo works offline if your cache is populated.
We hash everything, and access-control leverages your existing Git key infrastructure. Using Git commits you have full audits of every build.
A nice idea, but not really compatible with from-source packages. This approach will lead to a reimplementation of build-system features in meta-meta-build-systems. Build-system transpilation is a better approach in the long run (not to mention the other benefits).
We are source-first, but not handling binaries is impractical. We always check the hash of binaries.
We think so, but would love your feedback! 🤠