[Marathon] Switch build to bleep

[Baccata]

The developer experience when working on Smithy4s is currently not great, in particular due to the size of the matrix we're dealing with. I'm pretty sure switching to bleep will lead to a much better/consistent developer experience, thanks to bleep's pretty much instant startup and IDE update (which greatly facilitates moving from branch to branch in an always evolving build). It would also open the door to super precise caching, as the build is fully declarative and its parts could be used to determine when something needs to be recomputed.

However, before we even consider a serious switch, a number of issues need to be addressed. I'm opening this issue so that whoever wants to help towards that goal can contribute to the bleep development.

• [ ] bleep's test command must work across all platform (see https://github.com/oyvindberg/bleep/issues/233)
• [ ] bleep's artifact packaging facilities must be updated to allow for customising manifests
• [x] code-generation must work in bleep (see https://github.com/oyvindberg/bleep/pull/247)
• [x] bleep must notify BSP clients when its build changes (see https://github.com/oyvindberg/bleep/issues/274)
• [ ] a POC needs to be established to build SBT plugins with other build tools than SBT (including tests)
• [ ] the library update command needs to be amended to be more interactive (in particular wrt libraries like fs2/CE that publish sha-versioned artifacts).
• [ ] bleep should be handled by scala-steward
• [ ] bleep should check for binary incompatibilities similarly to SBT
• [ ] auto-completion should work for ZSH and fish (see https://github.com/oyvindberg/bleep/issues/240)

Why ditch SBT ?

In large projects, the loading time of SBT is detrimental to the developer experience. Moreover, it's not unusual to switch from one branch to another and having to reload the build and re-dump the bloop configuration into the file system. Additionally, in projects that have code generation, it's often the case that you need to switch between SBT and a bloop-driven IDE, paying for the cost of compilation several times. I've not found SBT's native BSP implementation to be really convincing, a number of features seem to be lost over bloop and it feels pretty sluggish too.

Why not mill ?

Though I'm a long time user/fan of mill, ever since it first came out circa early 2018, I don't think the story would improve much by switching to mill in this project. Loading the build for large builds is still reasonably slow (albeit less so than in SBT), and it takes a lot of time for things to get replicated in the editor. Moreover, I think newcomers are pretty confused by mill's OO-like command invocation, and the fact that the build is yet another way of using Scala to declare things prevents interesting patterns for caching.

Why bleep ?

I do think for large projects a fully-declarative build is probably the way to go, and bleep is quite interesting in that regard. Its "script" mechanism means that additional behaviour surrounding the build is isolated and does not make the build much larger to load, the commands are more intuitive than in mill (in particular because bleep doesn't allow for nesting and doesn't use characters that are require quoting in other shells than bash, like [ and ]).

Is this decision final ?

Nope. In particular, my team at $work is gonna be trying bleep in an isolated project, to see how it feels and we may discover some gaps that may become dealbreakers, in which case we'll probably fallback to mill.