search

LoopPerfect / buckaroo

The decentralized package manager for C++ and friends 🏝️
https://buckaroo.pm
MIT License
933 stars 33 forks source link

Cannot find a `list` command #137

Open adamretter opened 6 years ago

adamretter commented 6 years ago

How can I list all available packages, so I can:

a) determine if a package I want is available? b) see what package types are available. i.e. if I want a lib for http, there may be more than one option available via buckaroo.

Perhaps a buckaroo list command that takes wildcards and/or a buckaroo search command might help?

njlr commented 6 years ago

Hi @adamretter!

There is no facility for this in the client at the moment.

To browse the official packages, you can take a look at buckaroo.pm. There is a search box at the top.

Unofficial packages (that is packages on GitHub, BitBucket and GitLab) are not currently indexed. The only way to find them is to look for a buckaroo.json file in the repo. Here is an example.

If you can't find a particular package that you are looking for, please create an issue on the wishlist and we'll endeavour to port it for you 😊

adamretter commented 6 years ago

@njlr Hi there, I was initially interested as I make some contributions to RocksDB and I wondered about packaging that. Unfortunately if I understand correctly, then we would also have to adopt the Buck build system to be able to use Buckaroo. I don't think that is something we are likely to do.

njlr commented 6 years ago

Yes, all Buckaroo packages build with Buck. This is to give us a reliable way to glue libraries together (Buck generates linker flags etc.)

It is possible to use binaries that have been built by Buck in a non-Buck project, since they are predictably placed in the buck-out/gen/... folder. If you consider it worth it or not would be up to your team and your use-case.

It is also possible to go the other way, and call other build systems from Buck. You lose many of the benefits of Buck by doing this, but it can be a "good enough" solution. In this case, Buck acts as a "gluing layer" between binary files output by different build systems.

We wrote a brief article about the benefits of Buck, and there is a good talk from the Buck team too. The main reason that we use Buck is that it makes builds self-contained and reproducible. With CMake, it is very difficult to guarantee these things, which can result in "well it works on machine" type errors.

Regarding RocksDB, that is a Facebook project, which I understand already uses Buck internally, they simply haven't open-source the BUCK files yet. If you choose to port RocksDB I imagine that would be a good starting point.