https://kotlinlang.org logo
Title
s

sam

05/05/2021, 1:27 PM
Kotest 4.5 has been released. Feel free to share. https://kotest.io/docs/changelog.html
🍾 4
🎉 8
👍 5
:kotlin-intensifies: 1
p

Peter

05/05/2021, 4:00 PM
is it ok to use
kotest-extensions-testcontainers
4.4.3 with above?
s

sam

05/05/2021, 4:02 PM
yes, but you might as change the dependency to be https://search.maven.org/artifact/io.kotest.extensions/kotest-extensions-testcontainers since that's what will be updated moving forward
See changelog
1.0.0 == 4.4.3 of that dependency
From 4.5 onwards, the namespace for all extensions has changed to io.kotest.extensions and the versioning reset to 1.0.0.
So, for example, if you used the Spring extension, you would previously have added io.kotest:kotest-extensions-spring:4.x.y to your build. Now you would use io.kotest.extensions:kotest-extensions-spring:1.x.y
👍 1
p

Peter

05/05/2021, 4:02 PM
great, thank you!
d

dave08

05/06/2021, 9:23 AM
Will https://github.com/jmfayard/refreshVersions be updated with the new kotest deps? It seems like they haven't released a new version for a while, and now with 4.5, too many things have changed...
s

sam

05/06/2021, 1:24 PM
There was a PR I made months ago merged a couple of days ago, so my guess is they're back at updating it again
I will make a new PR with all the latest changes for 4.5
👍🏼 1
h

henrik

05/07/2021, 7:39 AM
no reason to use refreshVersions anymore now that Gradle 7 has native support for a shared versions catalog: https://docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml
s

sam

05/07/2021, 10:21 AM
That's really nice
b

Big Chungus

05/08/2021, 7:34 PM
Tbh, I still prefer refreshVersions as it's making version upgrades very easy. With catalogs you still need to find new versions manually
d

dave08

05/09/2021, 10:06 AM
I also like it better for code complete of the most common deps...
b

Big Chungus

05/11/2021, 6:39 PM
Catalogs generate dsl accessors too.
d

dave08

05/12/2021, 10:15 AM
True, but they need to be created by library users... libraries with many artifacts can be hard to maintain (like the tons of Androidx libs and test deps...) apart from the actual versions. It would be nice if library authors could provide catalogs... a bit more work for the library authors (but even users can PR these things...), but would make it VERY simple to manage lots of artifacts.
The downside of refreshVersions is that it's not really updated so often
b

Big Chungus

05/12/2021, 10:25 AM
That's the whole idea of catalogs, you can publish them to any maven repo, so I'd imagine big frameworks like spring will be publishing them with each version, same as BOMs
🤯 1
d

dave08

05/12/2021, 10:26 AM
So really all that's missing is managing versions then...
b

Big Chungus

05/12/2021, 10:27 AM
Another benefit of catalogs is that you can declare lib groups, so you could have all kotest artefacts under a single
implementation(kotest.bundles.master)
👍🏼 1
d

dave08

05/12/2021, 10:27 AM
That's nice... but meanwhile it might take some time for Android, Micronaut and the rest to adopt all this...
b

Big Chungus

05/12/2021, 10:28 AM
I'm thinking of writing a plugin that'd work with catalogs and would let you run
./gradlew upgrade-interactive
and allow you to interactively choose lib upgrades that are then reflected in your catalog
❤️ 2
s

sam

05/12/2021, 10:28 AM
Is catalogs gradle 7 only ?
b

Big Chungus

05/12/2021, 10:28 AM
Gradle 7 and they're still in feature preview
d

dave08

05/12/2021, 10:51 AM
I personally liked the refreshVersions approach to upgrading... having those comments there makes it easy to choose one to upgrade without having to go through all the deps and say "no".
b

Big Chungus

05/12/2021, 10:55 AM
Agree, however not sure how that could be represented in toml
d

dave08

05/12/2021, 11:12 AM
toml does support comments it seems. https://toml.io/en/
I just wonder if parsers support parsing/reading/writing them...
b

Big Chungus

05/12/2021, 11:15 AM
Yeah, but there are multiple ways where gradle lets you declare versions in toml, so it might be tricky keeping comments consistent
d

dave08

05/12/2021, 11:17 AM
A nice start would be the versions block... other places have version ranges AFAIK...
It seems like a simple properties file syntax in that block... so a simple regex could handle it with a bit of care.
b

Big Chungus

05/12/2021, 11:25 AM
A bit limiting, but I guess that's a start.
d

dave08

05/12/2021, 11:28 AM
Later, you could always extract hard-coded versions from the libraries block into the versions block to manage them there too...?
The thing is managing the naming...