Replace typesafe config for sconfig for Pekko 2.0.0

[mdedetrich]

This was brought up some time ago but I want to raise this again, basically moving from lightbend config to sconfig. Currently Pekko uses typesafe config as its main configuration library however there are many issues with it

• Lightbend config no longer really being maintained and aside from akka we seem to be the only main library using it (most of the Scala community has moved to sconfig)
  • Using a library that is largely unmaintained puts at risk of issues, given pekko itself has limited capacity its best to make sure our dependencies are well maintained. We have already begun removing libraries such as sslconfig for this same reason
• sconfig aside from being actively maintained, its used by many large non trivial projects including
  • scalafmt
  • scalafix
• sconfig supports all major versions of Scala (2.12/2.13/3.3) along with scala.js and scala-native. Pekko doesn't have these targets, but using sconfig helps open up this possibility
• sconfig has no real impact on java users, in fact aside from the raw package name/imports the API is exactly the same (this was done intentionally), see https://github.com/ekrich/sconfig/tree/main/sconfig/shared/src/main/scala/org/ekrich/config
  • The migration is so trivial that they actually provide their own migration tool

@raboof @pjfanning @raboof Thoughts?

EDIT: A pull request is now ready, see #2187. Turns out that while the changeset is large, 99% of it is just renaming imports and removing/adding () in relevant parts of Scala source code.

[pjfanning]

lightbend/config recently released a 1.4.4 patch release - I wouldn't call it unmaintained - just in maintenance mode, where only serious bugs get fixed
https://github.com/lightbend/config/releases/tag/v1.4.4

I know we are making breaking changes in 2.0.0 but I'd like to keep them limited and I don't see switching away from lightbend/config as being all that important (i.e. not worth the disruption).

[pjfanning]

#400 was the previous discussion

[mdedetrich]

lightbend/config recently released a 1.4.4 patch release - I wouldn't call it unmaintained - just in maintenance mode, where only serious bugs get fixed
https://github.com/lightbend/config/releases/tag/v1.4.4

This is debatable, because the whole reason why lightbend/config#789 was made is that serious bugs were not being fixed. Aside from bumping dependencies, nothing is really done on the project and Lightbend has explicitly said they are no longer interested in maintaining libraries. typesafe config right now is in almost as bad position as sslconfig

I know we are making breaking changes in 2.0.0 but I'd like to keep them limited and I don't see switching away from lightbend/config as being all that important (i.e. not worth the disruption).

Its actually the least disruptive change we have done so far. The api for sconfig is 100% source compatible with typesafe config (this was a deliberate design goal) with the only change being the package name. This means that if users don't use typesafe config API directly (which would be a large percentage) there is no visible change whatsoever and for users that do use the API directly, they only need to change imports.

[He-Pin]

I don't think we should remove it, as Akka is still using it, sconfig is great, but it's still a one-man part-time job.
The only way I think we should migrate is we split all Scala implementations into dedicated projects and then compile Pekko to Scala native and Scala Js, otherwise, I think we should keep it as it is.

[mdedetrich]

I don't think we should remove it, as Akka is still using it, sconfig is great, but it's still a one-man part-time job.

The entire scala center maintains sconfig, and it also has funding support. Typesafe config is in actuality far less maintained, otherwise I wouldn't bring this up

The only way I think we should migrate is we split all Scala implementations into dedicated projects and then compile Pekko to Scala native and Scala Js, otherwise, I think we should keep it as it is.

None of this is necessary, pekko already requires Scala and its going to be a depenency as anything else. The API for sconfig is deliberately written to be java safe (just like our javadsl api's are), in fact its entirely source compatible with typesafe config.

[mkurz]

The entire scala center maintains sconfig

Didn't know that. Can you link a resource confirming that? Also, why is it not hosted under https://github.com/scalacenter/ ?

[mdedetrich]

The entire scala center maintains sconfig

Didn't know that. Can you link a resource confirming that? Also, why is it not hosted under https://github.com/scalacenter/ ?

I don't think my statement here is entirely correct, the original main consumer of sconfig being scalafix/scalafmt are scala center maintained. I will update original post

[He-Pin]

Open-sourcing is about collaboration, not forking, if we can fix a bug in a fork, we can fix it in the upstream project too.

[mdedetrich]

Open-sourcing is about collaboration, not forking, if we can fix a bug in a fork, we can fix it in the upstream project too.

Except that typesafe config is not actively being supported, pull requests aren't being merged and lightbend said they are not supporting it aside from bare minimum. Please read lightbend/config#789, the community is actually seriously considering forking typesafe config because of this.

[janjaali]

Let me please add from user perspective, running a landscape of services and libraries with Pekko / Typesafe, that migrating to sconfig - even if low effort necessary - would create an additional burden to migrate to v2.0.0.
PS: Typesafe config is still a thing in the community, e.g., https://scala-slick.org/doc/stable/database.html which pekko persistence jdbc uses internally ;)

[pjfanning]

All that means is that pekko-persistence-jdbc users would end up with both config and sconfig jars on the classpath. That's not too bad.

[He-Pin]

I think so, that's totally pointless, we can do that once Akka drop it, Akka is a commercial project, and it's not cheap. If there are really big problems, they will have to compensate customers, so I believe they will fix the bugs. In that case, why switch? Can you guarantee that you will be online to fix bugs every day and give up your family and life? That's impossible, isn't it?

[mdedetrich]

PS: Typesafe config is still a thing in the community, e.g., https://scala-slick.org/doc/stable/database.html which pekko persistence jdbc uses internally ;)

Dependencies of pekko that happen to use typesafe config internally is a non concern, this is talking about base pekko. In cases like pekko-persistence-jdbc, writing a wrapper that goes from typesafe Config to sconfig Config and vice versa would be easy and trivial.

[mdedetrich]

I think so, that's totally pointless, we can do that once Akka drop it, Akka is a commercial project, and it's not cheap. If there are really big problems, they will have to compensate customers, so I believe they will fix the bugs. In that case, why switch? Can you guarantee that you will be online to fix bugs every day and give up your family and life? That's impossible, isn't it?

The reality is that akka has stated themselves they are not interested in fixing bugs for lightbend config where as sconfig has that committment.

The main reason I am seeing why akka has not dropped lightbend config is because they haven't released a breaking change of akka since the license change to BSL license so they are stuck with typesafe config until they release a breaking change of akka

[pjfanning]

I guess the key thing is that sconfig has a Scalafix conversion so the effort shouldn't be too much. I guess we could try to generate a PR and see what it looks like.
I'm neutral enough about this. I can be persuaded either way.

[mdedetrich]

One pain point is that sconfig has a scala-collection-compat dependency https://mvnrepository.com/artifact/org.ekrich/sconfig_3/1.11.0

Thats a fair point, although that also brings up another point which is that we have actually manually inlined code from scala-collection-compat because they accidentally made some breaking changes in their releases ages ago.

This has since never happened though, so we can probably safely remove this manual inlining that we did and just use scala-collection-compat directly.

Also means less code for us to maintain

[He-Pin]

@ekrich ping ~

[pjfanning]

There are no unmerged PRs in https://github.com/ekrich/sconfig. The team seem very active. Maybe the best question is planning around what happens if the maintainers need time off. One option if @ekrich was amenable would be to consider bringing sconfig to the ASF.

[mdedetrich]

There are no unmerged PRs in https://github.com/ekrich/sconfig. The team seem very active. Maybe the best question is planning around what happens if the maintainers need time off.

Most critically, they are not closing PR's that are actual bugs, obvious missing features i.e. lightbend/config#786 and lightbend/config#783

One option if @ekrich was amenable would be to consider bringing sconfig to the ASF.

I think adding more maintainers would be a more realistic/practical solution here.

[mdedetrich]

@pjfanning PR is up and ready #2187

[mkurz]

Similiar discussion in Play repo recently:

• Replacement for lightbend config library? playframework/playframework#13333

[mkurz]

@mdedetrich

1. Is there a specific bug pekko is facing caused by / in lightbend config?
2. Is there a feature missing in lightbend config that pekko desperately needs?

If both answers are no I would vote for keeping lightbend config.

[mdedetrich]

Woho, seems like Lightbend ("Akka") is watching this conversation here and they now start to work on it:

• docs: add alternative Rust HOCON implementation lightbend/config#825
• Fix minor typos lightbend/config#823

or maybe just coincidence...

To be honest, I don't know what is going on with Lightbend in this regard but this confusion is not inspiring confidence and just adding more weight to not be beholden to decision making that is so chaotic.

[mdedetrich]

Again, because it's supposed to be feature complete.

I know its feature complete, but there actual bugs which have remained open and Lightbend has themselves said that they are not going to solve bugs that doesn't personally effect them

Just adding my thoughts here. There other libraries that hardly get new releases because they are more or less "done".

Of course, the whole point of this discussion is get community thoughts.

[He-Pin]

Maybe we can just figure out how to fix that bug instead of a migration

[mkurz]

Which bug(s) specifically?

[mdedetrich]

Maybe we can just figure out how to fix that bug instead of a migration

Thats not on us, thats on Lightbend/Akka which is the problem. Lightbend has outright closed pull requests for bug fixes if it doesn't solve their problems, see lightbend/config#786 and lightbend/config#783 as examples.

There isn't anything more to add, Lightbend/Akka have made it clear they don't want to work on Lightbend Config anymore

[ptrdom]

In my opinion, ideally every core feature – such as config – should be internal or depend only on ASF projects, meaning both Typesafe Config and sconfig are problematic in that regard. So the three solutions I see are:

1. Asking for Typesafe Config or sconfig to be donated to ASF.
   • @pjfanning has already suggested this in regards to sconfig,
2. Forking Typesafe Config or sconfig into ASF.
   • I understand that @He-Pin is against this, but not all OSS is created equal, and ASF is a safer organization for long term health of a project than individual owners or most other organizations, which I feel is of particular importance for this case.
3. My personal favorite - dropping dependency on Typesafe Config altogether and going all in with programmatic configuration. Whether it is expansion of ActorSystemSetup or some other abstraction which would be internal to this project. Then have optional sub-projects that allow deriving this programmatic config from some other config library available, whether it is Typesafe Config, sconfig or whatever else there might be.
   • I understand that it is way, way more effort, but it seems most purposeful and forward-thinking, at least to me.

[He-Pin]

I put some effects on sjsonnet, maybe that's a try too.

https://github.com/databricks/sjsonnet

[He-Pin]

A DSL is hard to design, you will see @mdedetrich, I think you will finally fail on that, the HOCON is much complex than you think.

[mdedetrich]

We are not talking about a DSL or replacing HOCON, just that as an alternative to passing a HOCON configuration you can do something like

ActorSystem.create(
   ActorSystemConfig(
      provider = "local",
      guardianSupervisorStrategy = "org.apache.pekko.actor.DefaultSupervisorStrategy"
      etc etc
   )
)

[He-Pin]

I know, Kotlin and Scala 3 are both powerful on that, but still there is something that can't be expressed

[ptrdom]

I know, Kotlin and Scala 3 are both powerful on that, but still there is something that can't be expressed

Maybe you have an example in mind? The way I see a resolved HOCON config is that it is very directly translatable to a class hierarchy, so wondering what I might not be thinking about.

[He-Pin]

We can add a DSL-based configuration method, but I don't recommend removing support for HOCON, as it's already widely accepted by the community. I also don't recommend a major fork from Akka. We might produce a better design, or even a less polished one in some areas. Maintaining similar functionality and user experience will allow users to easily choose between the two frameworks. After all, some commercial projects are forced to use Akka due to supply chain requirements. I think this will benefit both projects.

I don't recommend investing effort here because I believe that as an open source project, our resources are limited, at least not full-time, so we should focus on more creative endeavors. If we could compile Pekko to Scala Native or Scala JS, I think that would make sense, but we already use a lot of MethodHandles and VarHandles, so the cost is a bit high.

As a Java developer, as are most employees at Alibaba. I simply want to improve performance and optimize the Java API experience.

[mdedetrich]

I don't recommend investing effort here because I believe that as an open source project, our resources are limited, at least not full-time, so we should focus on more creative endeavors. If we could compile Pekko to Scala Native or Scala JS, I think that would make sense, but we already use a lot of MethodHandles and VarHandles, so the cost is a bit high.

FYI, the effort neccessary to replace lightbend config with sconfig was trivial, PR is almost done #2187. 90% of the work was done by a single migration command provided by sbt-scalafix. Most of the work was actually adding in the MiMa exclusion filters.

As a Java developer, as are most employees at Alibaba. I simply want to improve performance and optimize the Java API experience.

Of course, no one is stopping you. As an open source project we have to cater to a lot of people and also a lot of potential problems.

[He-Pin]

1. Does the bug exist in sconfig?
2. Does the new feature get added to sconfig?

[ptrdom]

I have a feeling that Pekko will become a major fork from Akka no matter what Pekko does, and sooner or later easy migration will not be possible. Like for example Akka SDK - if a project is using it, Pekko has no alternative. So we can either choose to essentially stagnate in Akka 2.6, forever prioritizing backwards compatibility with legacy Akka 2.6 projects or eventually start providing unique, competitive functionality with future major releases.

[ekrich]

I can maybe chime in here. Recently, we have been working on making sure sconfig has all the fixes and features added in config since the original fork. We have not added some JVM and classloader specific ones but they could be added if really needed.

We have in the latest release work by @kastoestoramadus adding the ability to format HOCON code which would also allow a hoconfmt or configfmt application which would also check that the config file parses correctly. We have an additional fix that allows very long decimal numbers that is released in config but breaks MIMA compatibility so I have not released this yet to investigate and evaluate the impact and ensure we didn't make a mistake in the porting. This change was added in version 1.4.1 of config. There are also some additional formatting improvements showing MIMA incompatibility that are merged as well. This is not ideal especially for Waldemar who is adding these features for a company and waiting for a new release. As mentioned, there is only so much time in the day.

We also have also added ScalaOps from the Scala.js and Scala Native world to allow some functional code with Java collections to minimize and eliminate the use of conversions to Scala collections where collection compat is needed. The sites are mostly used for for which can be replaced pretty easily. The API uses Java types so converting is not really that helpful. Other potential performance improvement sites are the original Scala breakable sites which could be eliminated.

I have maintained this for about 7 years but I am not opposed to ASF or Scala Center or some other more permanent home. The Scalafix could be used for another package change if needed. Does Apache currently have Scala cross platform code?

[ekrich]

Well, I'd prefer not to add more - could it just be in the presistence project as a utility? The config format is another possible addition but that could be in scalameta perhaps. My priorities are really improving the code, test coverage, and Scala Native features such as embedded config files - this last one seems to be a tough one. Just adding the formatting features is challenging as explained.

[mdedetrich]

Well, I'd prefer not to add more - could it just be in the presistence project as a utility? The config format is another possible addition but that could be in scalameta perhaps. My priorities are really improving the code, test coverage, and Scala Native features such as embedded config files - this last one seems to be a tough one. Just adding the formatting features is challenging as explained.

True, although a proper implementation would go recursively down the config ast and change each ast node to the other libraries equivalent (which is a one to one mapping). This solution would be faster and may also be more accurate if a future divergence in parsing ever occurs.

[mdedetrich]

Well, I'd prefer not to add more - could it just be in the presistence project as a utility?

Yes it can be, but the other reason for having a ready on hand library is actually for the general user population of Pekko. A lot might still be using typesafe/lightbend config and can't move off of it (for w/e reason) and so having a library with a set of utility functions to easily convert to a sconfig config I would imagine would be quite helpful practically speaking.

At least from what I can tell right now, the main apprehension from users is that they are already heavily using typesafe config (largely I presume because other projects are using it) and this is a valid point.

I mean I could easily create the library myself, albeit it would have to sit under my org (mdedetrich) as a namespace which may not be that desirable. Could also put it into ASF but that may take a while.

[pjfanning]

@ekrich the ASF is about building communities and each community is quite autonomous in terms of what they build and what they release. One of the key reasons that we are debating switching is because there is a feeling that the existing config library is not very actively maintained and it would be nice if there was a replacement where there was enough of a community to ensure that the lib can continue to be maintained even if key contributors moved on.

[He-Pin]

@ekrich we need all features , because we don't know how users are using it.

And a new version without ccompat