Buckaroo API

[reiz]

This is a cool project and highly needed for the C/C++ community. Does buckaroo has an public REST API which offers an index of all the buckaroo projects? I'm working on the open source project VersionEye and we integrated already 17 package managers. I would love to add buckaroo as well :-)

[njlr]

Hi @reiz,

Buckaroo is designed so that it does not require a server to operate; it's more like Carthage than NPM. However, we do have an unpublished REST API as part of Buckaroo.pm. Perhaps we can document and release it.

I'll assign @nikhedonia to this since he wrote the web back-end.

[nikhedonia]

@reiz VersionEye looks really good and we would love to make integration as easy as possible!

At the moment we only have an undocumented GraphQL endpoint. However I'm happy to build a REST API on top of it.

Currently our server pulls from https://github.com/LoopPerfect/buckaroo-recipes/tree/master/recipes to get it's index. Maybe that's enough for now?

What REST API would be ideal for VersionEye ?

[reiz]

Hi @nikhedonia I think this here is enough for us: https://github.com/LoopPerfect/buckaroo-recipes/tree/master/recipes :-)

Can you tell me a bit more about the structure? Why are some json files in a directory and others not? I also noticed that the versions array inside of a JSON document always contains just 1 single element and it's usually not the newest one. Like here for example: https://github.com/LoopPerfect/buckaroo-recipes/blob/master/recipes/ar90n/msgpack11.json. Is that correct?

[njlr]

• Every Buckaroo package (or "recipe") has an organization and a package name. For example, boost/asio has owner boost and package name asio.
• recipes contains a list of JSON files and folders corresponding to organizations. The JSON file contains some meta-data about the organization and the folder contains the recipes of that organization. For example, see recipes/boost.json and recipes/boost/.
• Each organization folder contains the recipes that it owns. For example, recipes/boost/ contains asio.json, graph.json and so on.
• Each recipe JSON file contains one or more versions. For example, ijg/jpeg has two versions.
• Many of the recipes are quite recent, hence there is only one version. We add more versions based on what people contribute, user requests and what we see in our analytics.
• There is more information about recipe files in the documentation.
• As of 1.2.0, recipes can also be just GitHub repositories with a buckaroo.json file. We do not track these at the moment. More information.

So to summarize, the folder structure looks like this:

+ recipes/ 
+---+ org1.json
    + org1/
    +---+ recipe1.json
        + recipe2.json
        + ...
    + org2.json
    + org2/
    +---+ recipe1.json
        + recipe2.json
        + ...
    + ...

[reiz]

@njlr Thank your for the explanation. A couple more questions.

• Are the versions in the .json file related to GitHub tags? The versions in this json file https://github.com/LoopPerfect/buckaroo-recipes/blob/master/recipes/ijg/jpeg.json are not equal to the tags of the repository here https://github.com/LuaDist/libjpeg/tags. They are completely different.
• How are the versions in the .json files updated? Are they updated manually?
• The referenced GitHub repositories and tags can be deleted/renamed/closed any time from their maintainers. Is there are a system in place which documents deleted/renamed repositories and/or tags?

[njlr]

We lock down dependencies to an exact hash so that we can guarantee reproducibility. The .json files are updated manually. At the time of writing the recipe commit hash should match the tag, but if the author changes a tag then it will no longer match.

Of course, if a maintainer decides to delete some code from their host then the recipe will no longer work. We cannot prevent this, however we run automated scripts to detect problems. Since the recipes are tracked in Git, we have a full history of changes.

The cookbook at https://github.com/LoopPerfect/buckaroo-recipes can be thought of as a way to bootstrap the community with popular dependencies. The prefered model for creating new packages is for the user to host it inside thier own repository (docs), but this feature is quite new.