In our `module.yaml` files, is there a way to acce...

# kotlin-toolchain

[gbaldeck]

In our module.yaml files, is there a way to access versions from our libs.versions.toml file similar to how we use $libs?

[Tanish Azad]

Are you trying to use both gradle/libs.versions.toml and libs.versions.toml simultaneously?

kotlin-toolchain.org/latest/user-guide/dependencies#…

[joffrey]

@gbaldeck there is no way right now to access just the version strings, which I'm assuming you want to use to populate some versions under settings:, right?
Could you please share for which setting you wanted to have that? (just so I get a better idea of the case at hand, even though we know it's a general problem)

[joffrey]

What should make this slightly less of a problem is that we provide built-in catalogs for most libraries that depend on the versions from the settings. For instance, we provide $kotlin.* with a bunch of libs that you would use the Kotlin version for. We provide $compose.* for things that require the Compose version. So in theory you should still be able to configure each particular version in a single place (e.g. in a template that applies settings.kotlin.version or settings.compose.version ).
Now indeed, it would be best if all versions could be in the same place (e.g. the library catalog).

[gbaldeck]

@joffrey Yes it is in the settings block. I would like to have the kotlin, serialization, and JVM versions in the versions block of libs.versions.toml.

I am using templates to minimize the amount of times I need to set versions, but it would still be nice to have the versions in 1 file so that we don't need to jump around.

For example, the kotlin and serialization version in my base template below.

settings:
  kotlin:
    version: 2.4.10
    freeCompilerArgs:
      - "-Xannotation-default-target=param-property"
    serialization:
      enabled: true
      version: 1.11.0
    compilerPlugins:
      - id: dev.mokkery
        dependency: $libs.mokkery.plugin
#        options:
#          defaultMockMode: autoUnit     # Optional: strict, autoUnit, etc.
#          defaultVerifyMode: soft       # Optional: soft, exhaustive, etc.

dependencies:
  - $libs.kotlinx.coroutines.core
  - $libs.mokkery.runtime: compile-only

test-dependencies:
  - $libs.kotlinx.coroutines.test
  - $libs.mokkery.runtime
  - $libs.turbine

[joffrey]

Thanks, so yeah you're pretty much doing everything you can right now. We know that this isn't perfect. We're actually designing our own library catalog format (which might end up in project.yaml, and when that happens we'll think about version references)

[gbaldeck]

@joffrey Thanks will be happy to try that out and provide feedback when that becomes available.

One other question, if you look in my template above I am using the mokkery compiler plugin in the compilerPlugins block. I only need that plugin in my test compile though.

I have a workaround in my dependencies setting the mokkery runtime as compile-only. This allow the compiler plugin to be added but not included in the main application artifact.

Is there a way to specify the plugin for the test compiler only?

[joffrey]

Yes, you should be able to add it in the test-settings section instead of settings, just like you do test-dependencies instead of dependencies for the runtime:

settings:
  kotlin:
    version: 2.4.10
    freeCompilerArgs:
      - "-Xannotation-default-target=param-property"
    serialization:
      enabled: true
      version: 1.11.0

test-settings:
  kotlin:
    compilerPlugins:
      - id: dev.mokkery
        dependency: $libs.mokkery.plugin
#        options:
#          defaultMockMode: autoUnit     # Optional: strict, autoUnit, etc.
#          defaultVerifyMode: soft       # Optional: soft, exhaustive, etc.

dependencies:
  - $libs.kotlinx.coroutines.core

test-dependencies:
  - $libs.kotlinx.coroutines.test
  - $libs.mokkery.runtime
  - $libs.turbine

[suresh]

@joffrey Related to that, how can I apply config to just main settings, not the test-settings. My use case is, I have a library where main source has

freeCompilerArgs:
      - -Xexplicit-api=strict

But I don’t want strict explicit APIs for my test classes and functions. Right now, I am doing

test-settings:
  kotlin:
    freeCompilerArgs:
      - -Xexplicit-api=disable

which produces the following warning

ERROR warning: argument '-Xexplicit-api' is passed multiple times: 'strict', 'disable'. The last value will be used.

[joffrey]

Oh, yeah we're aware of this issue. We have actually no way right now to specify a main-only context. This requires careful thinking/design, so my issue was kinda left alone for a while:
KTC-4729 Support main-only settings (@main/@test contexts?)

Now, we had multiple people complain/report about this, and 100% of the time it was about -Xexplicit-api. So I believe that we don't need to implement the full complex feature to solve the vast majority of the problems, we can just define a custom field explcitApi, and decide that this one doesn't apply to tests:
KTC-5787 Support settings.kotlin.explicitApi property and ignore it for test sources