another qq - I saw the new test configurations followed kapt's

<config>Test

naming convention rather than the conventional

test<config>

convention used everywhere else. Was there a specific reason for this? If not - would you be open to changing it? This is always a huge headache when repo maintainers try to automatically manage some configurations for tests and have to add special rules for kapt's backward naming

yea i just literally copied kapt so it is easier for people to migrate. https://github.com/google/ksp/blob/master/gradle-plugin/src/test/kotlin/com/google/devtools/ksp/gradle/SourceSetConfigurationsTest.kt#L169 I'm open to changing it but it is up to @Jiaxiang and @Ting-Yuan Huang.

Sure, let's change it!

what is the right name btw ?

@Zac Sweers Can you give some concrete examples?

I believe it goes <base-name><other>

androidTestKsp? that does sound weird to me but maybe i'm too used to kapt

yeah androidTest puts it at the end too, so we would want

androidTestKsp

Are there any docs on this convention so we can document the change from kapt?

I have no idea 😅

Or maybe even still create those configurations and if someone uses, error out with a proper message

since it's in alpha and they just changed for anyone needing them in tests, I'd prefer just changing them

no i meant for people migrating from kapt

they'd be making a breaking change anyway since the configuration name changes. If they have custom gradle stuff looking for configurations by fuzzy naming, matching the existing conventions almost certainly exists anywhere that fuzzy naming looking for kapt

But for a user, let's say you have room, moving to ksp is simply applying the plugin and then replacing kapt with ksp. With this, people might think flavor specific configuration don't exist.

you could write a plugin to replace common libraries with KSP support with their KSP implementations? 😉

this also brings the case where maybe we should name the configuration

symbolProcessors

instead of

ksp

?

hmm, idk. ksp kind of reads better to me as a name for the configuration rather than the name of the thing you're adding to it

I'm in the team that would vote for registering all the variations of where ksp goes (beginning and middle) and writing error messages and AS warnings for the invalid ones. That makes it indifferent to decide if they go as prefix or suffix. People are certainly going to struggle with other aspects. Any help helps ✨✨

Hard disagree. That's like suggesting adding

ksp

,

kps

,

psk

, etc because people might typo it. That's not helping anyone, that's just adding API surface area to cover for people not reading docs

psk

is not an expected reasonable variation, so I wouldn't go that far. but there's arguments in favor and agains

kspTest

and

testKsp

. If it's not obvious to the people writing it, we should expect newbies (me included) spending time figuring out. Each little extra step contributes to the learning curve. I'd apply the 5% rule here: if we improve lots of things by 5% we get a dramatic improvement overall.

people not reading docs and just trying to use a different tool the same way as a old one isn't a learning curve, it's just people not reading docs IMO