I want to use a dependency compiled with 2.1.0 in ...

# gradle

[hfhbd]

I want to use a dependency compiled with 2.1.0 in a project using 1.9.0. it fails because the 1.9 kotlin compiler does not support 2.1, only 2.0 (+1). But why there is no KOTLIN_API attribute to prevent the dependency resolution using Gradle at first step?

[mbonnin]

Somewhat hot take, but I like it this way. An attribute would only make sense if there were multiple variants to choose from.
If not, it's duplicating information and I find it ok that it fails at compile time.

[hfhbd]

You could add another variant with a different api version.
Also, it is not a duplicate information. It is the same with the jvm release attribute.

[mbonnin]

That information is in the metadata (for Kotlin) and class file (for java). The .module file is just an easier way for Gradle to process that without looking into the jars

[mbonnin]

Another option would be to use separate maven coordinates

[mbonnin]

Gradle attributes are convenient but they do not work for maven consumers for an example

[mbonnin]

And more generally I'm starting to think they are abused in many places. Maybe not here but they're not always a silver bullet

[tapchicoma]

knowing UX problems of Gradle report for incompatible attributes I also have my doubts about this request 🤔

[tapchicoma]

and request is probably similar to: https://youtrack.jetbrains.com/issue/KT-57564

[mbonnin]

Looks like KMP is also migrating away from Gradle attributes: https://youtrack.jetbrains.com/issue/KT-68323

[hfhbd]

Regarding UX, there is https://github.com/gradle/gradle/pull/27858 available with Gradle 8.7+

[Alexander.Likhachev]

there is https://github.com/gradle/gradle/pull/27858 available with Gradle 8.7+

Note this failure description framework is an internal Gradle API

[mbonnin]

That's what is getting me itchy about attributes: there's a lot of Gradle specifics. Moving some logic to dependency resolution might be interesting but there's too much implementation details right now IMO