https://kotlinlang.org logo
Title
z

Zac Sweers

02/14/2021, 6:34 AM
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
y

yigit

02/16/2021, 10:55 PM
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.
👍 1
t

Ting-Yuan Huang

02/16/2021, 10:57 PM
Sure, let's change it!
I'll prepare a PR
y

yigit

02/16/2021, 10:57 PM
what is the right name btw ?
testKsp instead of kspTest ?
what happens to for instance
kspAndroidTest
?
t

Ting-Yuan Huang

02/16/2021, 11:15 PM
@Zac Sweers Can you give some concrete examples?
z

Zac Sweers

02/17/2021, 1:49 AM
I believe it goes <base-name><other>
let me check what androidTest does
y

yigit

02/17/2021, 1:49 AM
androidTestKsp? that does sound weird to me but maybe i'm too used to kapt
z

Zac Sweers

02/17/2021, 1:53 AM
yeah androidTest puts it at the end too, so we would want
androidTestKsp
y

yigit

02/17/2021, 2:37 AM
Are there any docs on this convention so we can document the change from kapt?
z

Zac Sweers

02/17/2021, 2:38 AM
I have no idea 😅
y

yigit

02/17/2021, 2:38 AM
Or maybe even still create those configurations and if someone uses, error out with a proper message
z

Zac Sweers

02/17/2021, 2:39 AM
since it's in alpha and they just changed for anyone needing them in tests, I'd prefer just changing them
y

yigit

02/17/2021, 2:41 AM
no i meant for people migrating from kapt
but probably not worth going to those lengths
i'm probably just traumatized w/ years of androidx development
z

Zac Sweers

02/17/2021, 2:42 AM
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
y

yigit

02/17/2021, 2:44 AM
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.
But anyways, i don't believe it is that important
We should just go with the right name and document
👍 1
z

Zac Sweers

02/17/2021, 2:45 AM
you could write a plugin to replace common libraries with KSP support with their KSP implementations? 😉
y

yigit

02/17/2021, 3:58 PM
this also brings the case where maybe we should name the configuration
symbolProcessors
instead of
ksp
?
z

Zac Sweers

02/17/2021, 8:49 PM
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
you could have things other than symbol processors on the configuration for classpath reasons
f

Fabio

02/18/2021, 10:13 PM
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
z

Zac Sweers

02/19/2021, 8:14 AM
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
f

Fabio

02/21/2021, 10:24 PM
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.
z

Zac Sweers

02/21/2021, 10:25 PM
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
and adds API surface area that has to be maintained forever