Add a MillRuntime external module to expose some dynamic values as ready-to-use dependencies

[lefou]

Some Mill runtime values are useful to be used in buildfiles, e.g. env variables, respositories, various versions ...

In most cases, those values need to be consumed via an Task.Input, since they refer to dynamically changing values.

For example every use of an env variable should use the Task.env API to get an up-to-date value. It also needs wrapping this call in a Task.Input to also properly capture any changes in a long-running Mill session (daemon or watch-mode).

Mill could provide an external module mill.runtime.MillRuntime that exposes most of these dynamic values. Uses could just use these tasks and derive there values from it without the need to make their own tasks a Task.Input.

The Task.env API could internally use the mill.runtime.MillRuntime.env task, (by use of @inline?), which would reduce the risk of a build to use a stale value.

It also allows the inspection of these runtime values via the Mill CLI.

Let's also discuss, if we can reduce the size of the TaskCtx API by moving some values into the MillRuntime module, or if we should keep both APIs.

[lihaoyi]

I think the new mill.define.BuildCtx module is basically this.

[lefou]

@lihaoyi

I think the new mill.define.BuildCtx module is basically this.

Oh, I didn't realized, that it provides tasks. BuildCtx looks a bit unfinished as it has multiple public defs with a 0-suffix in it.

It this module always accessible, so we could add an env task and possibly others?

[lihaoyi]

The idea for BuildCtx was that it exposed things that were scoped to a build. So things like the workspaceRoot or watchValue or whatever. It is in particular used to provide things that are necessary outside of a Task scope, e.g. needing to use watchValue when instantiating modules.

It doesn't currently have tasks, but we could make it an ExternalModule and putting some Tasks on it as well, since those follow the same pattern of "build-scoped things that are necessary outside of a task scope", such as env or meta-build tasks

The 0-ending things are legacy that got moved from elsewhere, we can certainly clean them up if necessary

[lihaoyi]

We could imagine exposing the entire meta-build's ScalaModule on BuildCtx so the main build can depend on parts of it as necessary, which would make it much easier to share data between layers of the meta-build and keep things such as repositories consistent across them

[lefou]

I think it might be worth to consider to add the repositories from the YAML-frontmatter to JavaModule by default.

[lefou]

Looks like we lost mill.runner.MillBuild external module, which allowed us to get the meta build level count.

• introduced at: https://github.com/com-lihaoyi/mill/pull/2719
• removed at: https://github.com/com-lihaoyi/mill/pull/3717

We currently have no way to ask Mill for the deepest meta-build, so we could re-add that levelCount to the proposed MillRuntime/BuildCtx module.