I'm not sure if it's already known about but versi...

# gradle

[zt]

I'm not sure if it's already known about but version catalogs are still unable to be used with configurations that have additional configuration as of 8.6

implementation(libs.filePicker.get().toString()) {
    exclude(group = "org.jetbrains.compose.material", module = "material")
}

I can do implementation(libs.filePicker) but then i cant exclude the material dependency
Probably just an oversight

[Javier]

KGP has its own dependencies interface. Are you in a KMP project?

Probably you can do outside the kotlin block:

dependencies {
    “commonMainImplementation”(…) {
        exclude(…)
    }
}

[Vampire]

That would then be this issue to vote and watch: https://youtrack.jetbrains.com/issue/KT-58976

[Javier]

Main issue with that is the missing phase to be able to generate the configuration accessors

[Javier]

As the plugin do that conditionally, the only way to get the accessors is by applying it in a convention plugin and later the convention plugin in the project

[Vampire]

missing phase to be able to generate the configuration accessors

Not really.
Anything that depends on the build script content cannot safely be done for usage within that build script, because you would need to execute the build script content which can be any arbitrary code to know what to generate, but you need the generated accessors to compile the build script, so typical hen-and-egg situation.
You would need another special block like plugins { ... } or pluginManagement { ... } that is extracted and evaluated separately from the rest of the buildscript with a possibility for plugins to provide some syntax in there or something like that. And that would not make the implementation majorly more complex, but also the usage much more confusing, which already is confusing at times.

[Vampire]

Gradle does "the same" KMP is doing, for the test suites.
And in the first versions they had the same problems.
They solved it, KMP would "just" need to follow suite in a similar manner. 🙂

[Javier]

How they fixed that in suites?

[Javier]

I haven’t used them yet

[Javier]

I would like an especial block for convention plugins that is checked before so applying anything conditionally still generates accessors

[Vampire]

How they fixed that in suites?

They did what the Kotlin issue title says. 😄
They properly modeled a type-safe dependencies block in there.

[Vampire]

KGP just has an Any receiving method there that is forwarded to Gradle which then know how to interpret the version catalog accessor

[Vampire]

But there you do not have an Action overload as it would be unclear what to configure as the notation is Any.

[Vampire]

That is why it works in the KGP block with only a version catalog accessor, but not with additional configuration

[Javier]

Ah, then just adding more functions, I see that as a workaround to the real problem, those configuration should be generated as it is done with the normal implementation and the normal dependencies block

[Vampire]

Well, the configuration cannot be generated, as they depend on the build script and you cannot execute the build script if you need the accessors to compile the build script. That's the hen-and-egg I mentioned above.

And no, it is imho not a work-around, but properly modeled in that case.
And it is not just more functions, they did some proper modelling there afair.
Have a look at the code if you are curious. 🙂

[Javier]

But the problem is third party integration, ksp + KMP for example. ksp + commonMain, etc. The basic interface only solves KGP problems

[zt]

I'm doing this inside KMP commonMain source set

[Vampire]

Then yes, as we assumed the issue I linked to is the reason.
Either use what @Javier suggested in the top-level dependencies block:

dependencies {
    "commonMainImplementation"(…) {
        exclude(…)
    }
}

Or if you want it a bit less string-y:

dependencies {
    val commonMainImplementation by configurations
    commonMainImplementation(…) {
        exclude(…)
    }
}