https://kotlinlang.org logo
Join SlackCommunities
Powered by
I think the consensus was ultimately that we split...
# kotest-contributors
s
I think the consensus was ultimately that we split the projects out?
o
If so, can coordinate the steps to complete via a dedicated TODO-list-like issue before splitting? So something like this example?
a
I'd still like more time to see if enabling configuration cache (and then fixing the resulting performance problems) will help improve the usability of the project.
Personally I would lean against splitting Kotest up. I agree that it would help with separate release cadences, but I suspect overall it will make Kotest harder to work with.
s
It will be more annoying on the build side perhaps (duplication) but it will make contributing PRs much easier for people as the scope will be way less. I know its easier for us because we are more familar with the codebase, but adding an assertions requires you to open up a project with tons of extra stuff for example.
It'll also mean we can have different reviewers for different projects if we want. Like I tend to look at the plugin/high level framework stuff more than the assertions which I largely leave to others.
a
Yeah, I can see some benefits. But I also think it could be confusing.
For example, at the moment anyone can edit a function marked as 
@KotestInternal
and immediately update usages across the project. But if the project is split, changing a 
@KotestInternal
function becomes more uncertain, and would need some additional checks. Is the function still in use in another project? Does it need to go through a deprecation cycle? How can we check?
s
I envisage most of those functions not being reused. I went over most of kotest common and like time compat, it can mostly go
a
Regarding scoping - I've seen some projects use codeowners. I've only briefly looked into it, but I think the intention is to help slice up a project so that it's clearer which developers are best suited for different sections. Have you looked into it?
s
I use it at work
a
I envisage most of those functions not being reused
Ah okay, that helps
s
There's no technical reasons we can't do what I want in one repo. It's more the cognitive overhead for new contributors of a giant codebase. And adding more and more complicated build scripts makes it even harder for newcomers imo. But if I'm the only one that feels this way I'll not continue to push for it.
a
I'm not completely against it, I can certainly see some benefits.
I think the cognitive overhead of multiple loosely coupled projects is worth considering too :)
the buildscripts of Kotest are top tier btw, much better than most Gradle projects, which is impressive given the number of modules and age of the project.
👍 1
o
Could you elaborate on what's particularly good in Kotest's build scripts? I'm always wondering about where we're just good enough and where it would make sense to improve. With Gradle, its huge API surface and documentation showcasing outdated practices, I'm never really sure whether there might be something missing that could improve things greatly.
a
Sure thing! • There's no cross-project configuration (e.g. 
subprojects {}
and 
allprojects {}
), and subprojects don't modify other project's build config. • Heavy use of convention plugins. These help separate out the nitty gritty build configuration from the declarative config (like the dependencies). The result is that when working in a subproject it's much easier to see the relevant build config for that project - you can just check the 
build.gradle.kts
to see what conventions are applied, and what config is declared. It's also much easier to add, move, refactor subprojects. They don't interact with each other in surprising ways. And it doesn't matter whether a subproject is nested or not (unlike Maven, or when using `subprojects {}`/`allprojects {}`).
And the benefits are that it's easy to turn on things like Configuration Cache and Build Cache that make the build MUCH faster
There are some messy things in there, like the Gradle plugin and BOM, but that's a contained mess, and it's more indicative of missing/problematic features in Gradle than a flaw in Kotest's build scripts.
o
Thank you for explaining! I still associate 
buildSrc
with some caveats, though right now I can't find the relevant info that made me abandon them and use repository-based locals plugins instead for my own stuff. Is my 
buildSrc
aversion actually outdated and in fact they are pretty much safe to use now? Also, I'm wondering whether we should improve Java API / JDK version management.
a
do you mean using something like 
./build-logic/...
and 
includeBuild("build-logic")
instead of buildSrc?
there are some downsides to buildSrc, but also some positives. The main downside that is brought up a lot is that if you make any edit to a buildSrc plugin, then all buildscripts in the project need to be re-evaluated, no matter whether they have a buildSrc convention plugin or not. The benefit of an includeBuild build-logic is it will only need to recompile subprojects that have plugins from build-logic, so it's more targeted... but what happens in most projects is that every subproject has a convention plugin. So everything gets re-evaluated anyway!
There are some other bits and pieces too, but generally I find that buildSrc is simpler and easier to use, and the downsides aren't really significant
Yeah I tried setting up toolchains in Kotest, but it's hard to configure :( I think there's a bug in KGP 1.9 so when you try to set the release flag to JVM8 it fails because at some point KGP tries to check if 1.8 == 8, without normalizing it
o
do you mean using something like 
./build-logic/...
and 
includeBuild("build-logic")
instead of buildSrc?
No, I really have nothing like that. I have independent projects for my Gradle plugins, store them in a local repository and reference them by ID in the 
plugins
block like every public plugin out there. Maybe this is less of an issue now, but my biggest obstacles were always the point where one of my plugins was interacting with the KGP (multiplatform) plugin. I don't remember exactly, but maybe this was related to the Gradle-embedded Kotlin version vs. the KGP plugin version.
Maybe it's this change in Gradle that I did not really factor in so far.
2 Views
Open in Slack
PreviousNext
Powered by