com-lihaoyi
WIP: streamline mill.api.Ctx usage
In general, we want use mill.api.Ctx instead of e.g. mill.api.Ctx.Log or mill.api.Ctx.Job when passing it implicitly to helper methods and workers. We typically need the other properties too when evolving the implementations or providing a second implementation. If we use mill.api.Ctx from the start, we can maintain a more applicable and stable API.
Not sure this is the right thing to do, as it means these methods would depend on a much richer API than they really need. e.g. In the test suite we have to create an entire DummyCtx just to satisfy the signature even if everything inside is unused.
I identified it as sometimes limiting in the past. Esp. when we added new things to the context like jobs or workspace or lately fork to the context. It typically results in binary-incompatible changes or impossible changes in the work case. The key is the fact, that a class/trait can better evolve over time. If we want to avoid this case you pointed out, we could alternatively invent a context version with all components being optional, which might be better suited for SPI (internal API) which also need to be tested in isolation.