Tobias Roeser

@lihaoyi Thanks for you thorough explanations. I think a link from the sub-project to the root or parent project would be the best solution. * It's analogue to the `import...

I'm not saying we are smarter that other tools or tool developers. But we (or I, to speak for me) also have issues with these other tools, others obviously don't...

I think the `module.sc` is a nice compromise. It means, `build.sc` needs to strictly reside above each sub-module, which is a limitation. On the other side, we don't need to...

About the deep `module.sc` in sub-directories discovery: The suggested approach is to search recursively in all sub-directories. It can be therefore hard for a developer unfamiliar with a project to...

For me, foreign modules never proved to be usable and I'm also not aware of any project that uses them. I'm all for removing them. Instead, we should think about...

@lihaoyi > @lefou what you suggest sounds reasonable. It would also prevent "accidental" picking up of random `module.sc` files deep inside the filesystem hierarchy > > On the other hand,...

We use the same version for Mill releases and its supportive high-level abstractions like `scalalib`. Technically, if we don't change scalalib, we could easily cut a (experimental/preview/unstable) `0.12` line, which...

@lihaoyi @lolgab What you think of creating a feature-preview-branch, where we merge some (binary-compatible) PRs like this one for early testing? I think, nothing beats an easily accessible development release,...

I think in context of this feature there should be some guidelines and/or restrictions, which magic imports work / should be used in which locations. E.g. A `import $ivy` worked...

I wonder how likely is it, that this PR breaks compatibility? It now needs explicit enablement via a `$`-import. That means, without it, Mill behavior won't change at all. Also...