I'm working on a custom Gradle setup using Kotlin ...

# gradle

[Vivek Modi]

I'm working on a custom Gradle setup using Kotlin DSL, and while exploring the nowinandroid project—specifically the convention/build.gradle.kts and libs.versions.toml files—I noticed an inconsistency in how plugin IDs are accessed from the libs.versions.toml version catalog in the build-logic:convention module.

[Vivek Modi]

gradlePlugin {
    plugins {
        register("androidApplicationCompose") {
            id = libs.plugins.nowinandroid.android.application.compose.get().pluginId
            implementationClass = "AndroidApplicationComposeConventionPlugin"
        }

        register("androidApplication") {
            id = libs.plugins.nowinandroid.android.application.asProvider().get().pluginId
            implementationClass = "AndroidApplicationConventionPlugin"
        }

        // ... more plugins
    }
}

[Vivek Modi]

Some plugin IDs use .get() directly (e.g., compose.get()), while others use .asProvider().get() (e.g., application.asProvider().get()).

[Vivek Modi]

From the libs.versions.toml, these plugins are declared normally under [plugins] or indirectly referenced.
My questions are:
1. What's the difference between plugin.get() and plugin.asProvider().get()?
2. Is one preferred over the other in certain scenarios?
3. Could this difference be caused by how the plugin is defined in libs.versions.toml?
Any clarification would be helpful! I'm trying to standardize how plugins are registered in the convention plugins module.

[ephemient]

it's just an artifact of the accessor types. if you have foo and foo-bar defined in the version catalog, then libs.foo doesn't have a .get(), as it's of a different type so that libs.foo.bar can exist. but libs.foo.bar has a get() because it has no nested children

[ephemient]

has nothing to do with being preferred or not

[Vivek Modi]

Thank you so much. I get it now