Third-party dependencies

Subrepos

Please also supports a concept called "subrepos" which allows fetching arbitrary dependencies and attaching build rules to them. These can be depended on from other build rules and generally used as normal.

Subrepos are defined using builtins like http_archive or github_repo. These download a remote file and extract it, and make the contents available to other rules. In most cases you can choose to attach a BUILD file to them, but it can also use an existing one if appropriate.

For example (as seen in the Please repo):

    
    
    github_repo(
        name = "gtest",
        bazel_compat = True,
        repo = "google/googletest",
        revision = "release-1.8.1",
    )
    
  

Rules within subrepos can be referenced using a triple-slash prefix on rules, anywhere where a build rule would normally be accepted. For example:

    
    
    cc_test(
        name = "my_test",
        ...
        deps = [
            "///third_party/cc/gtest//:gtest_main",
        ],
    )
    
  

Note that the subrepo label (third_party/cc/gtest) includes the package we defined it in earlier. In many ways subrepos mirror the feature in Bazel, but in this case are more flexible since they're not limited to being defined at the repo root. For compatibility, we also accept an @ prefix for subrepos instead of ///.

Comparison to other systems

For users familiar with Bazel, we expect that writing BUILD files won't be challenging, the main difference being that there is no direct equivalent to Bazel's WORKSPACE file. As mentioned above, third-party dependencies can occur wherever you choose to put them in normal BUILD files.

If you've used Buck before, the model is pretty similar to fetching Maven jars using the bucklet for it. This is not entirely coincidental since we were previously using Buck so initially Please had to mimic the same interface - but we also quite liked it and decided to keep on in the same way.

If you're coming from Gradle or Maven, it's a little more alien due to being less language-specific and requiring full transitive dependencies to be specified.
There is an add-on rule which is the closest equivalent; it works by communicating with Maven repositories to find dependencies and generating more BUILD rules for them. This can be a little unreliable though, since the Maven package format is complex, and your dependencies aren't fully within your control and can change between builds - we recommend maven_jar instead, but understand it's more work to set up.

requirements.txt files from Python are not usually especially difficult to translate using pip_library; again we require listing transitive dependencies explicitly, but this is not normally too onerous for Python.
Since Please needs to know precisely what will be output, the rules can sometimes need a little tweaking when the output names don't correspond to the package names (or often a package outputs a single .py file instead of a directory).

go_module works pretty similarly to the usual go get tool, but again only outputs a single package at a time. Writing up the dependencies can be eased by using something like go list -f '{{.Deps}}' <package> to discover all the dependencies for the package in question.

Verification

An important concept of Please is strict validation of inputs and outputs of each build. Third-party dependencies are an important case for this since they allow code you don't totally control into your build.
Please has two explicit mechanisms for controlling this.

      
      
    pip_library(
        name = "six",
        version = "1.9.0",
        outs = ["six.py"],
        hashes = ["sha256: 0c31ab7cf1a2761efa32d9a7e891ddeadc0d8673"],
    )
      
    

      
      
    [licences]
    accept = MIT
    accept = BSD
    reject = MS-EULA