Dragging @russhwolf into the convo.

And @mrf7 and @samhill303

I go back and forth on whether I think the no-arg module was a good idea. Manual configuration is a little bit more work, but it's much more flexible when people have different use-cases. and it's easier to evolve over time. In a couple years when everyone on Android has migrated to DataStore, it might be confusing that multiplatform-settings-no-arg still uses SharedPreferences. But it's hard to migrate without breaking existing users. That said, that's maybe less of a concern for a logging library than a persistence library.

I go back and forth on whether I think the no-arg module was a good idea.

Personally I don't really like such no-arg modules.
IMO the goal should be to make the setup/config as easy as possible without losing flexibility.

I wouldn't mind having to create a simpel global property since it gives me the flexibility to immediately tweak the default config to my project.

I like no-arg very much. Just adding the library and writing Logger.info("hello") to let it log to a sensible destination is a great onboarding experience. If it's as simple as System.out.println() people will use it right from the start and can do configuration of additional appenders (for Crashlytics, mailing, etc) and so on later.

I think Kermit has the most starts because it does target more Kotlin/Native targets than the others. So for my SwiftUI Multiplatform app with macOS it's actually currently according to https://kamp.petuska.dev the only one aside a project https://github.com/PocketByte/kotlin-kydra-log (which I didn't looked further into)

It likely has the most stars because of KaMPKit and our marketing team in general (although we've put zero effort into marketing Kermit specifically). I would not imagine the additional platforms really impact the popularity much, although I don't have hard stats. That said, I think any solid KMP library should attempt to support as many platforms as it reasonably can.

Approach thoughts. We can chat with JB about kotlinx, but in my experience, they encourage community libraries for things that are reasonable. If you look through the kotlinx libraries, they tend to be critical things that are difficult to implement. coroutines, date-time, serializable, etc. I could see a logging, but the reason we all have logging libraries is because they aren't difficult to implement. The difficultly is shipping a feature set that makes enough people happy, and having it be extensible enough for those that want more.

So, JB might totally want to do one, and we can chat with them, but my guess is they'd be happy to encourage us to do it.

I would currently vote Kermit, but I am obviously biased, so put that in the calculation. We'll need to discuss feature set, but if we come to some reasonable agreement, we could manage the resources. We're trying to be very deliberate with our open source. Fewer libraries, but make sure they're done well. We were planning a formal refresh and release of Kermit anyway, so this makes sense to me. We can definitely add people as core maintainers, and we'll certainly put some marketing time/effort into promoting it, so I think we have a shot at making it the "default" logging option. We're also open to renaming it, btw :)

Clog I'm not opposed to, although we carve out time for team members to work on open source as part of "marketing". It's kind of the reality of paying people to work on open source, for a consulting company anyway. We do some work outside of our repos, but it is harder to commit resources. That said, I'm not sure there's a ton of sustained work once the core feature set is complete. That's kind of in the feature discussion.

Yeah, a logger does seem too "simple" yet too large in scope to be an official kotlinx repo. But JB does seem to encourage the use of some particularly good community libraries in their documentation (Decompose and other Touchlab repos, for example), so we should aim to get some kind of buy-in from them with a logger to really help it get solidified in the greater community.

I agree that Kermit is probably the best place, I just didn't want to assume your team would be able to commit to it. I would happily deprecate Clog and move my efforts over to Kermit to be a maintainer there.

I think if we can have a general agreement on design and features, we could support it. I'm also happy to add others as core maintainers. To discuss.

I'm already getting ahead of the plan and poking around the code. Doing some performance experiments and trimming the api a bit: https://github.com/touchlab/Kermit/pull/90/files#diff-781d19b0af675f4efb32aac5e965027e38349614d258dbbacc569248c10d12f8 The function calls and stack-depth issue isn't really a big issue. Config and what's supported I think is more of a discussion. I do think we should add a module that is global/static for debug dev purposes, but keep core as small as possible. That kind of thing. Thinking through this over the weekend.

I also need to loop in the rest of the team who have actually been working on this, but we've been intermittently discussing updates for a while, so I think everybody would be excited for a phase 2.

For it to work as a general-purpose logger, we need to avoid thinking specifically about the mobile use-case.

Definitely! What I am trying say is that some of the features could be platform/implementation specific.
Which might make it easier since these features don't have to account for the limitations of other platforms/implementation.

Got it, yeah we're on the same page then. Just need to find the right balance there, where we don't push so much to the client that it becomes difficult to set up. An "integration" artifact like Multiplatform Settings has with multiplatform-settings-no-arg could go a long way in helping with this

There's a lot here. Haven't gone through all, but some comments.

They will just need to annotate the top-level property with SharedImmutable.

I may not understand what you're saying, but that wouldn't be mutable, by definition. It would need to be an atomic, and each log call would wind up looking at it, which is the issue. You can't really "initialize" a SharedImmutable with something, easily anyway. You can't like call a method with the starting config, and set that to a global immutable. It's like a quantum thing. Trying to set it means you've already "observed" it, so you can't set it. You could read a lazy value into it, but IIRC, that will be backed by some form of atomic anyway.

It may be possible to hold limited global config in some kind of native CPointer, and use an expect val with a get() to access it, but I don't know what that does performance-wise. It would avoid atomic threading overhead, but we'd be in weird territory and would need a fair bit or research and justification.

which is where the Kotlin ecosystem lives right now

I had a much longer comment here, but cut it. If we mean to say that the ecosystem may change with a better logging implementation, I'd say the Android ecosystem largely morphed out of the JVM server ecosystem, and has collectively made decisions to mimic or reject various patterns. If the Android library ecosystem has not yet embraced common loggers, I would not expect that to change. It's not really a Kotlin thing. Mobile libraries are far less likely to include dependencies, as a general rule. This is much less of an issue on the server.

I may not understand what you're saying, but that wouldn't be mutable, by definition.

Yeah. Including a global logger in the library would require it to be mutable else it won't be configurable.
But if sharing the global logger with dependencies isn't required the global logger could be defined by developers allowing it to be immutable.

You mean they define their own? Like:

@SharedImmutable
val myLogger = someLogConfig()

Yeah, that works fine.

OK. Circling back on status. We've been doing a fair bit of internal debate on various things. There's a lot to cover, but we've landed on what I think is a rough cut for next major version of Kermit. That includes:

1. Renaming of core artifacts. "Logger" is the main class rather than "Kermit", etc.
2. Mutable config and Global logger is available.
3. Log calls can either be "regular" or lambda-arg calls. Lambda calls are inline, and if the config disables them, you should avoid significant processing.
4. Platform default log writers are selected on init, so general usage should have no real config needs. iOS/Darwin is a little different because NSLog cuts off statements after 1024 chars, which is not ideal for stack traces, so "default" on iOS is just println. Something to revisit later.
5. Crash loggers for crashlytics and bugsnag.
6. A "log stripper" compiler plugin. Optional, of course. If you want to strip log statements out altogether, you can configure this plugin. Say you only wanted "warn" and above in your release build, this plugin will replace log statements of lesser severity with noop statements at compile time.

That's the overview. The plan is to push a 1.0, and discuss other enhancements going forward. In particular, the compiler plugin may get "log around" and "log time" options to wrap functions. That kind of thing.

We should be doing a push with all of the above tomorrow-ish as an RC.

Sounds very promising to me. Thanks for the update.

Yeah, this is looking really great. I'll start playing around with the RC, and once it's stable, officially deprecate Clog and start moving my stuff to Kermit. My deprecation plan is to replace the internals with Kermit, but keep the Clog API as a wrapper around it for compatibility.

Also, once the new Kermit goes stable, we should try to get some of the other minor loggers on board with it in a similar way to what I am doing with Clog, to help redirect traffic toward that one repo and improve its ranking when searching for "kotlin logger" or "kotlin multiplatform logger". Kermit is nowhere to be found in the Google results for either of those two queries.