module.mill will only be found, when same extension as build.mill

[lefou]

Mill now provides support for alternative file extensions: .mill, .mill.scala and .sc. But a <dir>/module.mill is only found, when the main build file has the name build.mill. If it is named build.sc, the sub-module is only found when it is also has the .sc extension, namely module.sc. This is irritating and doesn't seem intentional.

If this should be intentional, we should document it and print a warning for each file Mill is going to ignore.

[lefou]

Looks like we currently only support the consistent use of a same file extensions for all build.<ext> and package.<ext> files.

mill/runner/src/mill/runner/FileImportGraph.scala

Lines 186 to 189 in f66304d

	val buildFileExtension =
	buildFileExtensions.find(ex => foundRootBuildFileName.endsWith(s".$ex")).get
	val nestedBuildFileName = s"package.$buildFileExtension"

That means, if the top build file is build.mill.scala, all sub-modules need to use the package.mill.scala file name.

Although I like that this results in projects with consistent build file names, I find it quite limiting in projects in transition. Whatever the reason is to choose one extension over the other, there might be different reasonings fordifferent sub-modules and allowing non-consistent names would be better.

I think we should either warn if we ignored directories which contain a supported file but with different extension or don't enforce a consistent file extension at all but only warn if we find more than one supported file in one directory.

What do others think?

[lihaoyi]

Currently the different extensions have somewhat different semantics, e.g. w.r.t. how import $file and stuff work. So I think it might be confusing to mix them. Better to raise an error or warning

[lefou]

Currently the different extensions have somewhat different semantics, e.g. w.r.t. how import $file and stuff work. So I think it might be confusing to mix them. Better to raise an error or warning

Can you elaborate a bit. I think the only extension we handle specially is .sc for backward compatibility. But .mill and .mill.scala should be interchangeable, which they currently aren't.

[lihaoyi]

Can you elaborate a bit. I think the only extension we handle specially is .sc for backward compatibility. But .mill and .mill.scala should be interchangeable, which they currently aren't.

That is correct, but I would expect people who care about transitioning projects would indeed be the ones who have some build.sc and the rest either all build.mill or all build.mill.scala, which is the case where there is a semantic difference so we (and the user) may need to be careful.

I can't think of a use case where someone would want to have a mix of build.mill and build.scala, which is the case where there is no semantic difference and we can freely grab whatever build file exists.

[lefou]

@lihaoyi Can you list the semantic differences?

[lihaoyi]

@lefou IIRC the main one is that .sc files (best-effort) follow the old discovery semantics, where file must be imported with import $file before being used. .mill files instead do the recursive discovery of package.mill files and find any .mill files adjacent to them.

The .sc semantics were left (mostly) in place in an attempt to ease the migration, so projects could update to 0.12.0 without having to mangle their build file layout at the same time

[lefou]

Thanks. I think we should make that info about different import-handling available to our user as well.

I can't think of a use case where someone would want to have a mix of build.mill and build.scala, which is the case where there is no semantic difference and we can freely grab whatever build file exists.

I can. Imagine a larger project where not all challenges are solely technical but also social.

[lihaoyi]

I'd be ok with allowing mixed .mill/.mill.scala files in the same repo