Is it possible to use a placeholder for a module version?

[asarkar]

import $ivy.`com.goyeau::mill-scalafix::0.4.2`

Is it possible to use a placeholder for the version string (0.4.2) above? $file.versions.scalafixVersion or ${file.versions.scalafixVersion} don't seem to work.

[lefou]

This import is a shorthand notation for the regular ivyDeps in the meta-build. So, if you want more control, you can explicitly use a meta build and manage your dependencies there.

See https://mill-build.org/mill/extending/meta-build.html

[lefou]

• Documentation should provide a simple example of a meta-build #4311

[asarkar]

I'm trying to externalize all versions to a single file versions.mill. If I create a meta build, where should this file be located, and how would the meta build as well as individual module builds refer to it? If I put it in the project root directory (same level as mill-build directory), the meta build can't find it, and if I put it in the mill-build directory, the module build can't find it.

Please note that the Helper Files section in the docs doesn't address the issue of sharing files between meta and regular builds.

[lefou]

Is there even an overlap between the versions you need in the meta-build and the ones you need in the build? Nevertheless, here are some ideas.

Since .sc and .mill files will have to met certain constrains and are further processed, it's best to place all shared code into .scala files.

There is this section: Sharing Source Code between build.mill and Application Code, which is about sharing code between the Mill build and your application code. But technically, it is applicable to meta-builds too. Just replace "build" --> "meta-build" and "application" --> "build". Please note, that meta-builds can have meta-builds itself. It's a recursive structure.

[asarkar]

There's an overlap. As in my original question, the goal is to externalize the scalafix version in a file. scalafix is used in a module build, but as per your earlier comment, the version can only be declared dynamically in a meta build. Thus, this meta build needs to be able to read the version from the file. There's no scala code to share as such.

[lefou]

Alternatively, you could just generate a simple source file under mill-build/src/Versions.scala with the version, then you can avoid the meta-build on the second level.

https://mill-build.org/mill/extending/meta-build.html#_sharing_libraries_between_build_mill_and_application_code

[asarkar]

It seems really convoluted to read from a file and spit it out verbatim into another generated file. I wish there was a simpler way for builds to share files with meta builds. 😒

[lihaoyi]

You can use the meta-build to share code between the main build and applications https://mill-build.org/mill/extending/meta-build.html#_sharing_source_code_between_build_mill_and_application_code. I'm not sure exactly what you are trying to do but this seems like it should do it

[asarkar]

As I mentioned above, I'm trying to externalize all versions in a file, including scalafix module version. I started with a <root>/versions.mill file, but it appears there's no way to share this file between the meta-build and regular build. I think a meta-build/src/Versions.scala file can be used instead, but atm, I can't get the compiler to not rewrite this file in Scala 3 significant indentation syntax, which fails compilation because mill still uses Scala 2. I'll revisit this ticket when mill upgrades to Scala 3.