Will potential removal of custom (i.e. not compile/test) in sbt have adverse effect for sbt-native-packager

[mdedetrich]

Not sure if the maintainers are aware, but there is discussion at sbt 2.x potentially removing custom configs which this project uses pretty heavily (i.e. Debian/Docker are treated as their own configs).

If this is a concern should probably voice your concerns here sbt/sbt#7189

[muuki88]

Thanks a lot @mdedetrich . I will take a look.

[muuki88]

From the sbt discussion (sbt/sbt#7189 (reply in thread))

There are a few options. The easiest and most consistent one, would be to prefix all tasks/settings with the respective package. For example in docker there are

• dockerBaseRepository
• but Docker / publishLocal

The custom config is only used, when a setting is reused. So we don't reuse settings. dockerPublishLocal would be the new way to publish docker images. Even though this generates a lot more settings, it's easier to use IMHO.

What I'm sure will happen, that people start using Tasks to custom scope things, e.g.

val docker = settingKey[Unit]("this is now my config scope")

docker / publish := ???

However I would't want to go down that road with sbt-native-packager and use the opportunity to consistently rename all settings and do all the other breaking changes stacking up for years.