loopperfect / buckaroo Goto Github PK

For example, the target of this recipe is :utf8:

{
  "name": "utfcpp",
  "license": "BSL-1.0",
  "url": "http://utfcpp.sourceforge.net/",
  "versions": {
    "2.1.0": {
      "url": "[email protected]:njlr/utfcpp.git#2a13df14e883cc119e3b18c9fe5bf2e4d0e9295e",
      "buck": {
        "target": "utf8"
      }
    }
  }
}

Perhaps the easiest way is just to run buckaroo install automatically.

We should include some documentation in the CLI itself so that users can quickly figure out how things work.

Currently we print exceptions directly at the CLI. Instead, we should have a notion of "human-readable" exceptions, which can be shown to the user. We should leverage the type system to ensure that only human-readable exceptions are shown at the CLI.

We put a config.json file in the user's home directory, but we should also provide an option to have a project local config.json.

We should investigate having a shared build folder so that builds can be shared between projects.

We should provide aliases for common commands like NPM does:

• npm install and npm i
• npm uninstall and npm u
• etc...

This adds friction when writing recipes.

We should add a tracking URL to the config file. Users should be able to opt-out the first time they run Buckaroo.

The project-level BUCKAROO_DEPS file contains all resolved dependencies. It should only contain immediate dependencies.

For example:

buckaroo version

We also need to add a version definition somewhere in source-control.

e.g. Google Test

NPM has a nice feature where you can depend on a version 3.*, 1.2.*, etc. We should support the same.

This may involve some changes to the tokenizer, since we already have versions and wildcard as tokens.

compare for example oktal/pistache git-version vs zip-version

We should provide a small cookbook of commonly used libraries, including:

• json11
• Boost
• range-v3
• rapidjson
• rxcpp
• poco
• openssl
• Eigen
• Open CV
• Tensorflow
• observable
• Caffe
• json
• protobuf
• Bitcoin
• linenoise (C++)
• Mars
• Albert
• leveldb
• imagemagick
• imgui
• CNTK

For example when asking for a project name.

This allows us to match GitHub usernames more easily.

For example:

buckaroo install bost 1.3.0
There is no package called "bost". 
Did you mean boost? 

Tried buck a few months ago and cpp compilation on windows didn't work there yet.

Instead of just picking the latest version, narrow down the set of acceptable versions by applying requirements.

We should support BUCK that live outside of the source repo. This allows us to provide packages that we do not have commit access to.

If the user tries to install some-package and both some-package and some_package are available, we should warn the user. Fake packages are a potential security risk.

Buckaroo install $org/$mod $ver will fail if folder $org/$mod/$ver already exists and is not a git controlled folder. However buckaroo complains that repository could not be fetched.

This happens if you touch $org/$mod/$ver before running install

error message:

java.io.IOException: java.io.IOException: org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: /home/gaetano/Projects/buckaroo-tests/test2/buckaroo/oktal/pistache/0.0.1

Removes:

• .buckconfig.local
• BUCKAROO_DEPS
• buckaroo/