buckaroo

The world needs a Bazel package management system so the Bazel community can collaborate on projects like this. Buckaroo [0] is the closest I have seen but it’s Buck focused and they have not rolled out Bazel support. I think ultimately it needs a company like npm that can upstream the needed changes to Bazel itself so that it supports these workflows better. With the right focus you could hit cargo levels of ease of use, but for large multi-language projects. 0 - https://github.com/LoopPerfect/buckaroo

No but this will be covered by buckaroo [1] [1] https://github.com/LoopPerfect/buckaroo/issues/314

Overall Buck and Bazel are quite similar as they are both converging to Starlark DSL. However there are still some differences: Buck is much more opinionated than Bazel. Buck models slightly better C++ projects[1] and currently it's remote cache is more efficient[2]. Bazel is more extensible and offers also remote execution. Bazel has a bigger community and it's roadmap is public. There has been more than 350 C++ [4] libraries been ported to Buck for the Buckaroo Package Manager[3]. There are also technical details that manifest in some odd ways but are not significant. There is a nice paper by Simon Peyton Jones (creator of haskell) and others that goes into the design details [5] [1] https://github.com/bazelbuild/bazel/issues/7568 [2] https://github.com/bazelbuild/bazel/issues/7664 [3] https://github.com/LoopPerfect/buckaroo [4] https:/

We think Buck is great. It's Deterministic hermetic builds and it's composable and declarative high-level build description language made packaging very easy. We built even built a package manager for Buck: https://github.com/LoopPerfect/buckaroo Currently we marketing it for C++ but it can be used for any language that is supported by Buck.

This is amazing! As one of the creators of a distributed package manager for C++ and friends [1] we made a funny discovery: Many C libraries that a big chunk of the ecosystem depends on, have not been updated for many years. Some of those can only be downloaded from sourceforge or ftp server. Even worse, some libraries are copy and pasted from project to project and have no actual home. We uploaded them to github and started maintaining them. If you know any abandoned C/C++ projects or C/C++ projects you need a hand in maintaining, we are happy to help. [1] https://github.com/loopperfect/buckaroo

Buckaroo and Nix serve different needs. You can use Buckaroo in Nix https://github.com/LoopPerfect/buckaroo/wiki/FAQ#nix

I'd like to add Buck and his siblings Bazel & Pants to this list. Buck is used by large companies like Dropbox, Facebook and AirBnB. Additionally I want to mention my company released also a package manager that uses buck as a packaging format: https://github.com/LoopPerfect/buckaroo And so far over 320 libraries have been ported to buck and are maintained by our bots: https://github.com/buckaroo-pm

Thanks for pointing this out, we mention it now in multiple places: https://github.com/LoopPerfect/buckaroo/wiki/Installation#te... https://github.com/LoopPerfect/buckaroo/wiki/Telemetry We gather this data so we can improve Buckaroo and it's ecosystem.

Uncool guys, you have hidden telemetry. I don't see anything in the docs about this. https://github.com/LoopPerfect/buckaroo/blob/2714cd4c9e20235c4a090d21d0f60a0a9f17e… https://github.com/LoopPerfect/buckaroo/blob/master/buckaroo/Telemetry.fs This should be opt-in not opt-out or be clearly mentioned in the docs how to turn it off.

> I don't really see how it is even possible to automatically download and build those projects. so i mean what e.g. conan does is acknowledge this and require that package creators provide "recipes" that tell conan how to build the project. buckaroo seems to take a similar approach: https://github.com/LoopPerfect/buckaroo/wiki/Creating-a-Pack... i will say that in my time using conan to attempt to solve for compiling an application for x86 and a few flavors of ARM, this is NOT a silver bullet.. a huge fraction of third party libraries we tried to pull in needed to have their recipes modified to build correctly.

Great article. Some thoughts (mostly informed from design of Buckaroo https://github.com/LoopPerfect/buckaroo/ ): - Cost of creating a package must be low (ideally the package just lives in source control). This encourages code reuse and therefore testing. - Verification of changes must be easy. Git is a great tool for this - we can review patches between versions, rather than whole versions at once. - It should be easy to extract dependency graph (including transitive deps) so that you analyze who you are trusting. - There must be a verifiable chain from package source to package bundle (NPM fails here, do you really know the source code reviewed on GitHub is what went into the bundle on the NPM registry)? Better yet, have no bundles at all, just source code + build instructions. - Reproducible installations (usually implemented via lock

PureScript has a C++ back-end, which is an interesting prospect: https://github.com/andyarvanitis/purescript-native Our development process is very pleasant. We use VS Code, .NET Core and Ionide as an IDE. I find an IDE essential for languages with global type-inference. For bundling, we use Core RT to create a self-contained application. This is then bundled using Warp (https://github.com/dgiagio/warp) to generate a single binary. The script is here https://github.com/LoopPerfect/buckaroo/blob/866ae97ffc82ab8... The final binary size is quite reasonable: - Linux 66.1 mb - macOS 63.9 mb - Windows 35.4 mb I haven't investigated why Windows is so much smaller!