https://kotlinlang.org
Join Slack
another qq - I saw the new test configurations followed kapt's `<config>Test` naming conventio...
# ksp
z
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
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
Sure, let's change it!
I'll prepare a PR
y
what is the right name btw ?
testKsp instead of kspTest ?
what happens to for instance 
kspAndroidTest
?
t
@Zac Sweers Can you give some concrete examples?
z
I believe it goes <base-name><other>
let me check what androidTest does
y
androidTestKsp? that does sound weird to me but maybe i'm too used to kapt
z
yeah androidTest puts it at the end too, so we would want 
androidTestKsp
y
Are there any docs on this convention so we can document the change from kapt?
z
I have no idea 😅
y
Or maybe even still create those configurations and if someone uses, error out with a proper message
z
since it's in alpha and they just changed for anyone needing them in tests, I'd prefer just changing them
y
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
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
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
you could write a plugin to replace common libraries with KSP support with their KSP implementations? 😉
y
this also brings the case where maybe we should name the configuration 
symbolProcessors
instead of 
ksp
?
z
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
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
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
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
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
5 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by