Consider using Please as a build system

[sagikazarmark]

In the last year, I've been on a hunt for a build system. You can read about that journey in my blog post. tl;dr I chose Please as my go to build system:

• It's written in Go, so I can easily contribute
• It's fast (eg. faster than Bazel)
• Supports incremental building and testing
• Supports code generation
• Supports other than code dependencies

Introducing a build system like this has downsides as well:

• While make is a thin wrapper around go build, Please (and similar build systems) require more intimate knowledge (with Please and go build tools) to debug issues. Everybody knows go build, but not everybody knows Please.
• Go module support is quite new. I've worked closely with the Please maintainers for months to make that happen. I'm confident enough to use it in other projects, but it's something to consider.
• Adding a go dependency requires an extra step (eg. go get package@version && go mod tidy && plz tidy)

All in all: I'm definitely used to the incremental build and test feature of Please in other projects and I love it. I also like that it can reference everything in its metadata language, so everything can be described in a single build process. At the some time, it comes with some costs (getting to know Please). We can probably keep it simple for outside contributors though.

@dexidp/maintainers What do you think?

[JoelSpeed]

I'm not hugely familiar with systems such as bazel and please, so will need to do a bit of research before I can comment properly, but that said, could you expand on the following (all related) questions:

• What is the benefit to Dex of introducing a build system? (you've mentioned downsides and why you suggest please, but not upsides)
• What problems are you trying to solve here?
• Does Dex have a problem at the moment that makes it difficult to develop on?
• How would introducing please make this easier?

[sagikazarmark]

Thanks @JoelSpeed for the questions.

I've been working on Dex a lot lately (mostly testing changes) and I found that the current dev workflow with Make has too many moving parts:

• You need to (re)build dex: make -B dex
• You need to (re)build the example app
• You need to (re)start dex
• You need to (re)start the example app
• You need to maintain a dev config
• make test is not really helpful during development (e2e tests needs some parameters, but you can't run only some of them via make. you can use go test, but then you have to configure the parameters yourself)

Please can automate a lot of those tasks:

• Build and run multiple targets at once
• Watch for changes and rebuild/restart targets
• Run specific tests without having to manually define parameters (even watch changes and automatically rerun tests)

I'm pretty sure make can be improved a lot to gain some of those features, but Please won me over on the little things (like you can reuse build rules easily: https://github.com/sagikazarmark/mypleasings, friendly CLI interface)

Additional advantages of Please:

• incremental builds (only rebuild what's changed)
• hermetic builds
• self-contained build environment (Please can even download Go and use it internally)

To answer your questions:

• I think a build system like this makes development workflows better (comes with features not provided by make)
• Problems are listed above, I think it's too complicated to develop Dex at the moment. If everything works fine, the build system makes things easier (but if something goes wrong, it really gets in your way).
• The interface and tools provided by the build system makes the developer experience better IMO (see the features above, compared to "pure" make)

Hope that answers some of your questions. I try to discuss some of those topics in my blog post as well.