Bazel Integration

[mark-dropbear]

Hi everyone,

I was wondering if someone could point me in the right direction as to what level of integration if any there is between Dart's build system and general tool chain and Bazel? I was looking at doing a number of projects this year that are going to be span multiple languages and was wondering if it was a realistic goal to even consider having a a cross language build platform to drive a fast and reliable dev loop.

[jakemac53]

There is no supported path from the Dart team for this, but it is most certainly possible to do. However it would be a lot of work.

We could possibly provide some guidance if you wanted to try and take this on, as we do use bazel internally. The support is just not something we can reasonably open source because it has a lot of google specific logic in it.

[bivens-dev]

I actually have a spin off of this original question which is more about the idea of wrapping other toolchains with Dart build.

A specific example I have in mind was Dart’s gRPC integration which as it stands right now is quite a clunky manual process that involves downloading multiple binaries and hooking them up and invoking them via the CLI interface. It’s really not a particularly smooth experience.

Would you say Dart’s build system might be a good fit for taking care of downloading the binaries for whatever platform you’re on, and essentially abstracting all of that away? I feel like @jtmcdole might have had a package like this at one stage but I don’t recall.

I was just trying to get a feel for different use cases that might make sense with Dart Build.

[jakemac53]

build_runner itself is not well suited today to downloading external binaries (or interacting with them at all)

we have considered in the past adding some features to make it better for that, basically you need some sort of "environment" hook, where a builder can download any dependencies it needs, and also check if they have changed at all and signal that back so that it can invalidate all its outputs.

[bivens-dev]

For what it’s worth I just rediscovered the package I was originally thinking about and discovered that it actually has nothing to do with build_runner which honestly surprised me a bit but also I guess that settles that for now.

[jakemac53]

For what it’s worth I just rediscovered the package I was originally thinking about and discovered that it actually has nothing to do with build_runner which honestly surprised me a bit but also I guess that settles that for now.

Actually that package is interesting, because since it encodes the configuration in a file (including protoc version), it would actually be safe to integrate with build_runner. Basically you would write a builder which consumes this configuration as the primary input, and then outputs the downloaded files to a specific asset path inside the package which contained the protofu configuration file.

It requires you to be explicit about versions in the file probably, but it might work out reasonably well.

[bivens-dev]

Thanks for that follow up, I think that does actually help point me in the right direction of what a reasonable path of integrating other tool chains might look like.

Are there any particular footguns or arguments against something like this that I should be aware of that immediately come to mind?