Rename ivy stuff

[alexarchambault]

It seems using "Ivy" to refer to dependencies is confusing users. All the more that

• Apache Ivy isn't used any more to fetch dependencies
• 99.9% of the time, these refer to dependencies hosted on Maven repositories (putting ~/.ivy2/local aside)

I'm not sure what should replace it: just "dependencies" seems right, but might confuse people using Mill for non-JVM languages. "Maven dependencies" or "JVM dependencies" might work. That could give:

def jvmDeps = Agg(
  dep"com.lihaoyi::os-lib:0.11.3"
)
// or
def jvmDeps = Agg(
  jvm"com.lihaoyi::os-lib:0.11.3"
)

[alexarchambault]

Plus no one refers to those as "Ivy dependencies" in JVM ecosystems AFAIK. "Maven dependencies" seems to be more used.

[lihaoyi]

I agree

[lefou]

I think mvn would be a nice option since we target Maven repositories. dep is a bit to generic, and jvm a bit misleading (we don't select JVMs and we also use if for Scala.JS and Scala Native artifacts). We could introduce the alternative StringContext right away. No need to wait for 0.13.

[lihaoyi]

We should rename ivyDeps at the same time? That one may be more tricky to do backwards compatibly, but we could have a new def mvnDeps task that defaults to def ivyDeps so people can override either

[lihaoyi]

There's a lot of ivy terminology spread throughout Mill, might be easier to do a big-bang rename in 0.13.0 rather than trying to shim jvm versions of everything, but that would cause difficulties cross-building plugins

[lihaoyi]

I wonder if Scala3's @targetName annotation can be used to rename this in user code while maintaining binary compatibility?

[megri]

I'm a bit off when it comes to the finer details of maven- versus ivy-deps, but wouldn't mvnDeps be confusing as well if artefacts are being pulled from let's say sonatype? Why not just deps ?

On the same note, one nice thing that could come with having string context prefixes would be to solve the "colon-hell" (which unintentionally sounds like a bowel affliction); that is we could have java"group:artifact:version", scala"group:artefact:version", sjs"group:artefact:version" etc without fiddling around with colons. It may be too many variants to be comfortable, but it's worth considering.

[lefou]

I'm a bit off when it comes to the finer details of maven- versus ivy-deps, but wouldn't mvnDeps be confusing as well if artefacts are being pulled from let's say sonatype? Why not just deps ?

Technically, coursier does support Maven and Ivy Repositories, but effectively, most users use a Maven Repository. Maven Central is a Maven Repository and even many semantics used in Mill originate in Maven semantics.

It often helps in domain modelling, to avoid being too general. Since we don't support python or javascript dependencies here and also don't intend to support them, I think dep is just too general and will open new questions like: Why don't we use it in the PythonModule?

On the same note, one nice thing that could come with having string context prefixes would be to solve the "colon-hell" (which unintentionally sounds like a bowel affliction); that is we could have java"group:artifact:version", scala"group:artefact:version", sjs"group:artefact:version" etc without fiddling around with colons. It may be too many variants to be comfortable, but it's worth considering.

I really like this idea. In the end, all these StringContexts produce a mill.scalalib.Dep (possible moved to javalib or a shared coursier package later), so we keep the same underlying data structure. What these string contexts provide is convenience, and your suggestion seems to improve on that..

[jodersky]

dep is a bit to generic

+1 to that. Since we're in the process of adding python and javascript, I think dep is too generic, unless we can come up with something that works for all ecosystems.

[jodersky]

On the same note, one nice thing that could come with having string context prefixes would be to solve the "colon-hell" (which unintentionally sounds like a bowel affliction); that is we could have java"group:artifact:version", scala"group:artefact:version", sjs"group:artefact:version" etc without fiddling around with colons. It may be too many variants to be comfortable, but it's worth considering.

This sounds interesting indeed. I think it would feel very natural for the other ecosystems too, jvm or not. For example, we could add a pip"<package><qual><version>" or python"<package><qual><version>"

[lefou]

One idea is to reserve the mvn qualifier for dependencies strings formatted as for Maven. I remember vaguely, those can contain up to four colons and can encode details like the package type/extension. Ideally we chose something collision free to start with, e.g. java, scala, but these will likely produce qualifier collisions.