Limit `Task.Source`s to only targeting subfolders of the enclosing module that are not in sub-modules

[lihaoyi]

This is a limitation that Bazel has, and it's worth considering if we should as well. There's some trickiness with things like cross modules that can share the millSourcePath, but overall I think we might be able to make it work.

[lefou]

So, what we want here is a new exclude feature in PathRef?

[lihaoyi]

@lefou no, what I mean is to make both of these fail

object foo extends Module{
  def bar = Task.Source(millSourcePath / "../bar")
}

object foo extends Module{
  object bar extends Module{}
  def qux = Task.Source(millSourcePath / "bar/qqux")
}

Both currently work: Task.Source can refer to anywhere and millSourcePath is just a helper, so you can refer to paths outside your millSourcePath (first example) and paths within a nested module's millSourcePath (second example). This ticket would be to make Task.Source only able to refer to things within its enclosing module and not within any child enclosing modules

[lefou]

I'm not convinced we want to restrict Source/Sources per se. As a flexible build tools, we should allow non-standard setups.

If we know, some path constellations are most likely not what the user wants, we should try to detect that and warn (or what ever) the user, but we should make situations that occurs to developers now and then easy.

Yes, there are situations, esp. as sometimes presented in discussions and chat rooms, that don't make sense to a more experienced developer. Nevertheless, I love Mill for being the tool that does not stand in the way if I have a legit use case. Referring outside of the moduleDir/millSourcePath of the current module is something I needed more than once. Even referring to something outside of the current project is IMHO a legit requirement. Yes, there may be opinionated monorepo setups, but we should not enforce them in our general purpose nfrastructure. Instead, modules specially made for specific use cases should enforce their expectations, if needed.

[lihaoyi]

Yeah I don't think we should break any existing use cases without an easy migration path. #4524 surfaced some of these uses cases that Mill has internally.

#4486 already makes folder subpaths the "default" API that's documented for people to use, so that should solve 90% of them problem of people using the more powerful constructor accidentally. The only question is if there is further restrictions possible, or not, in which case there's no way forward.

[lihaoyi]

Going to close this for, since it seems the gain is limited (just a bit of tidiness) and the use cases that violate this rule aren't uncommon (e.g. modules loading config file from Task.workspace), and anyway the default user-facing behavior is to use sub-paths so we have most of the user-facing benefits already. We can revisit this in future if we find need for it