Kermit 2.0.0-RC4 Gradle Plugin for Log Stripping Example

[codesplode]

Description

I can't seem to find an example or means of getting the kermit log stripping plugin to function when upgrading to 2.0.0-RC4.

The feature is mentioned on the Kermit website but not mentioned at all in documentation or samples.

id("co.touchlab.kermit") version "2.0.0-RC4" yields an "UnknownPluginException" from Gradle, but the same works with version 1.2.2

I'm happy to help with documentation for this once I learn how to get it working again myself.

Thanks

Thank you for another great utility library.

[russhwolf]

I think the plugin wasn't published for 2.0.0 because we weren't sure it was useful or if people were using it. Were you depending on it in 1.x?

[codesplode]

Apologies for the late response. Yes, we were using it to strip logs from ios builds, but can remove it if you don't think it has value or is too much to maintain. We like the idea, but understand if it distracts from the primary features. Also happy to help and learn if there is something we can do to help keep it around.

[lppedd]

Stripping log calls would be nice for low level libraries that want all possible optimizations.
Example: I'm building a TCP/UDP multiplatform library and while logs are ok during development, I don't want the overhead in production.

[nicolasf]

I'm also interested in this.

I did a quick attempt on using proguard to remove the log calls, but unfortunatelly it didn't work. Probably some small mistake on my side. I'll debug later.

Here are my proguard rules, on top of the optimized defaults:

# Remove all logging calls from the co.touchlab.kermit package.
-assumenosideeffects class co.touchlab.kermit.Logger {
    public final void v(...);
    public final void d(...);
    public final void i(...);
    public final void w(...);
    public final void e(...);
    public final void a(...);
}
-assumenosideeffects class co.touchlab.kermit.Logger$Companion {
    public final void v(...);
    public final void d(...);
    public final void i(...);
    public final void w(...);
    public final void e(...);
    public final void a(...);
}

[kasem-sm]

Hey, did you get it working?

[nicolasf]

@kasem-sm unfortunatelly not. I didn't have time to test this further.
I'll probably look into it in a couple of months, but as far as I know this should bo doable with proguard.

[kpgalligan]

Moved to discussions. Earlier versions of Kermit had a compiler plugin to strip log calls completely. It was removed in 2.0 because for its entire existence, I never had anybody mention they actually used it, and we never wound up using it on anything ourselves.
The operation is conceptually simple. Adding it back wouldn't be too hard in theory. Testing it and feeling comfortable about what it's actually doing would need some thought. That's more of an irrational fear than a practical concern.

The practical concern would be getting issues from users. A mysterious, unrelated bug in production might be blamed on the plugin. Not a huge concern, but this does happen from time to time for various libraries we publish. It's pretty difficult to say for sure that a library we wrote didn't cause a problem, even if there's no reasonable way it could. You'd need a repro, but these kinds of issues often only manifest in prod builds, or out in the field. A compiler plugin that stripped operations seems like a prime suspect for mysterious problems. But I digress.

Practically speaking, the surface API of Kermit has changed somewhat, so 2.0+ would need some adjustments to the original plugin to find and remove the calls. Nothing major, but that's what would need to happen.

In addition, the compiler plugin api isn't considered stable, and might have breaking changes between Kotlin versions. That was another factor in the decision to remove it completely. Effort vs outcome.

So, it's a maybe? For our current roadmap on other projects, it wouldn't be super high on the list. However, if there was interest and somebody wanted to submit a PR, I think we'd consider publishing it again, with lots of "this is experimental" disclaimers.