Please 15.9.0 is here!

We've been hard at work and we're very excited to share what we've been up to! This is the first milestone newsletter so sit tight, it's a big one!

If you're new to Please, Please is a community driven, bazel-like multi-language build system with a focus on flexibility for mono-repos at scale. Get started here!

Clustered builds!

Please now supports clustered builds through the REAPI (Remote Execution API) which will enable superior scalability and incrementality. More information on this can be found here.

Improving interoperability with existing build servers is an ongoing piece of work, however if you're trying to set up remote execution for your project, we'd love to hear from you. Come on over to our gitter and say hi!

More platforms!

Please is now available on more platforms than ever! FreeBSD joins ranks alongside Linux and macOS as the third platform to receive binary releases. The linux binary now also runs on MUSL based linux distributions.

We're scoping out support or Windows; come over to our gitter if you'd like to help! See #1284 for more information.

First time setup

We're always aiming to make please as easy to use as possible. Configuring a new tool can be a daunting task. That's why please now guides you through your first time setup!

plz init is getting much smarter! We've started with golang, detecting a go.mod file and setting the appropriate config options to help you get started as fast as possible. There's also an interactive language setup via `plz init go` to guide you through enabling Go in your project. Expect to see similar love come to all the major languages: Java, Python, C and C++.

Golang!

Following on with the general trend to make Please as easy as possible to get started with, we've put a lot of work into Go!

Go test compatibility

If you're migrating from go build, or working on a pure go project, it can be jarring that Please runs tests from the repo root whereas go runs them from the package directory. To make it easier to migrate existing Go projects, and improve compatibility with IDEs and tooling, you can now change this behavior by adding the following to your config:

    [go]
    GoTestRootCompat = true
    

This will make Please run tests from the package directory just like go test would!

Project setup

As I mentioned, Golang is the first language to get the plz init treatment! If you're migrating from an existing go project, plz init will detect any go.mod file and set up your import path in .plzconfig automatically!

Please will also if your go installation is not available in the path you have please configured to look in! This was a common pitfall for a lot of first timers with please.

We've also simplified configuration of go in please! Simply set GoTool or GoRoot in your .plzconfig and you're away! No need to set both! Please will now figure out GoRoot or GoTool from based on whichever you configured!

Speaking of go installations

Worried about how to manage go installations across all your developers machine, CI workers, all running different operating systems? Then you should try go_toolchain()! Please will then automatically download the correct distribution for your platform, and build the SDK for the target platform if needed, making your build portable like never before!

Simply define your toolchain rule as such:

    # //tools/go:toolchain
    go_toolchain(
        name = "toolchain",
        version = "1.15.2",
    )
    

And then add the following to your .plzconfig:

    [go]
    GoTool = //tools/go:toolchain|go
    

Go get v2 modules

You can now specify the module major version in go_get(). This allows Please to download and install a go module and correctly handle the new import path. For example:

    go_get(
        name = "some-module",
        get = "github.com/some/module/v2",
        revision = "v2.0.1",
        module_major_version = "v2",
        ...
    )
    

This module will now be available to your go code as "github.com/some/module/v2".

We've made go_get() more specific about its outputs. You can now have multiple go_get() rules for the same module that install different packages. This can really help resolve cyclic dependencies which were a real pain before.

For the rule authors out there!

There have been some huge improvements to the build language over the recent releases aimed at addressing some common pain points when writing build rules.

Output directories

Traditionally dealing with rules where the outputs are difficult to know beforehand has been a major pain point. This problem cropped up commonly in code generation, downloading remote files, or just when a rule has a lot of flat outputs. The old hat approach to this is to find . -name *.go or the like and add these outputs via a post build function. Yuck!

Output directories aim to solve this problem by specifying a directory as the output root of your rule. Any files that end up in here are outputted as if they were in the package directory. In the build language, this looks a little something like:

    build_rule(
        name = "gen",
        ...
        cmd = "mkdir _out && $TOOL generate $SRCS -o _out",
        output_dirs = ["_out"],
        ...
    )
    

For more information on output directories, check out the documentation here!

Entry points

Another major pain-point in Please has been tooling that expect some resources to be in place in order to run. For example, javac expects to be run from within a jdk installation folder so it can dynamically link to its libraries.

Entry points address this problem by allowing you to name a subset of the output files of a rule as entry points. These can then be referenced with an annotated build rule later on:

    build_rule(
        name = "jdk",
        ...
        outs = ["jdk"],
        entry_points = {
            "java": "jdk/bin/java",
            "javac": "jdk/bin/javac",
        },
        ...
    )

    ...

    build_rule(
        ...
        cmd = "$TOOLS_JAVAC ..."
        tools = {
            "javac": ":jdk|javac",
        },
        ...
    )
    

See entry points for more information.

New built in functions and command replacements

The're have been a number of small additions to the build language in the recent releases:

• Added removeprefix(...) and removesuffix(...) string utils to the build language.
• Added subrepo_name(...) which will return you the subrepo name of the current package. This is extremely useful for setting default configuration for third party subrepos.
• Added $(out_dir ...) and $(out_locations ...) command expansions. See more here.