`@jetbrains` Could we have kotlin version added to...

# multiplatform

[Big Chungus]

@jetbrains Could we have kotlin version added to gradle metadata attributes, please? This would be useful in determining library compatibilities.

Also would play a key role when consuming it and deciding which schema/attributes to expect, since those seem to be quite volatile between versions

[Robert Jaros]

For me it seems like a wrong direction. I can accept compatibility problems only for the most integrated libs (like coroutines or serialization). But for all other libraries Kotlin version shouldn't be an issue. If not - we would end up like Scala users ;-]

[louiscad]

Well, since Kotlin 1.4, Kotlin/Native binary compatibility didn't break, and I read this is as designed and part of the reason compilation is slower than before (though other improvements are planned or undergoing in this area).

[Big Chungus]

@Ilya Goncharov [JB]?

[Ilya Goncharov [JB]]

@dsavvinov Could you please take a look?

[dsavvinov]

I read this as request to improve detection of compatibility of libraries, with a suggested solution of adding a gradle attribute of Kotlin version. Correct me please, if I got the initial issue you’re trying solve wrong.

The request itself is totally reasonable, and that’s something we definitely discuss from time to time and something we might work on future (though we don’t have it in the plans for 1.4.20 at least), see this issue: https://youtrack.jetbrains.com/issue/KT-37780.

The suggested solution is one of the viable options, but it’s a subject of some design, as gradle attributes a) compiled into published artifacts (thus, remain in the ecosystem ~forever) b) affect dependency resolution => we have to think carefully about introducing new attributes lest we get ourselves into an awkward situation, where mistakes/underdesigned decisions in the past attributes scheme block or significantly complicate some improvements (we had such situations already 😞 ). It’s not a bad option, just wanted to say that it’s a little bit more complicated than “just add the attribute” :)

[Big Chungus]

I was thinking of something like kotlin.metadata.version attribute which would reflect the kotlin version that produced the artifact. So in the future if you do choose to change the schema, people who are consuming it could just add anotheer processor implementation to their system and decide which processor to use by this attribute. My personal use case is this:

I'm writing a maven repo scanner that's looking for kotlin multiplatform libraries. To determine that, I'm depending on the following variant attributes in gradle metadata:

* org.jetbrains.kotlin.js.compiler

* org.jetbrains.kotlin.native.target

* org.jetbrains.kotlin.platform.type

Now since the available attributes or attribute names might change (as anything, really), it'd be good to have a single 100% stable attribute for kotlin version to indicate which shcema a given module file follows so that if you guys add/remove/change some of the attributes in the future, I could maintain backwards compatibility of my scanner by keeping old schema processor and just implementing another one to be used when kotlin version attribute is detected as x.y.z or even as semver blob 1.4.*

Happy to discuss this further if you guys think it'd be useful info to make a decission.

[Big Chungus]

Again, my particular case is not a matter of binary compatibility, but rather gradle metadata schema compatibility

[Big Chungus]

A suitable place for such attribute could be at $.component.attributes.kotlin.version

[dsavvinov]

my particular case is not a matter of binary compatibility, but rather gradle metadata schema compatibility

Ah, I see, sorry! That’s an interesting request, and indeed something we haven’t thought about thoroughly yet (mostly because not much people currently work directly with attributes schema). We’ll discuss that in the team

[h0tk3y]

@Big Chungus
Hi,
I think your request is quite reasonable, and having Kotlin attribute schema version (or, even wider, the publishing layout version, as it can change without affecting the attributes, as in 1.4.20) somewhere in the published metadata could really be useful.

However, the idea of adding such an attribute needs to be considered very carefully, as the primary purpose of Gradle attributes is to affect dependency resolution by establishing variant compatibility, and, if I understand it right, this Kotlin publishing schema version should not add anything to the behavior of variant matching.

Ideally, we could add it to some other place in the module metadata than variant attributes, but I'm not yet sure that the Gradle .module metadata format has such a place (or is extensible enough).
If it doesn't, it's still worth trying to introduce the attribute in a way that it doesn't affect variant-aware dependency resolution. Maybe we could add it as a unique attribute com.example.kotlin.version (where com.example is the component ID) – this way it should never be matched across different components, but still, there are possible clashes if the components don't have unique names.

Could you please describe what other data your repo scanner reads from a repository? Maybe there's some other place we could put the Kotlin publishing layout version.

[h0tk3y]

For example, I see that the .module metadata format has this subtree, marked as optional:

"createdBy": {
    "gradle": {
        "version": "4.3",
        "buildId": "abc123"
    }
}

It would be nice to add createdBy.kotlin there, but I'm not sure that's the intended use. I'll have to ask the Gradle team about that.

Another option is to add a non-default capability into the module that will never be requested by our tooling (and requesting it manually won't make any sense), and to put the publishing layout version to the capability variant's attributes.
`It is marked as optional, so it would be nice to add

[Big Chungus]

Honestly, for my use-case I only need some property in gradle metadata (doesn't really matter where exactly as long as it's always provided in the same place). Such property then would be used as an entry-point of metadata parsing to figure out what schema/attributes to expect. Again, this has nothing to do with variants for my use-case, but rather with module file schema as a whole. Essentially a version of kotlin plugin that produced this module file. The bellow addition would fully cover my use-case.

"createdBy": {
    "kotlin": {
        "version": "1.4.20"
    }
}

Does that clarify things for you?

[Big Chungus]

To reiterate, this should not be an indication of module's compatibility or participate in variant resolution, but rather a safe hook for when the module file itself needs to be parsed to indicate what schema was being used to create it.

[h0tk3y]

Got it, thank you! Just having the Kotlin plugin version there might not be enough, as in the course of migration to a newer publishing schema, a single Kotlin version might potentially publish modules with different layouts, depending on the migration opt-in flags. We'll think about the proper place and the necessary information to write there.

[h0tk3y]

Here's the issue to track: https://youtrack.jetbrains.com/issue/KT-42943