search

sbt / sbt-native-packager

sbt Native Packager
https://sbt-native-packager.readthedocs.io/en/stable/
BSD 2-Clause "Simplified" License
1.59k stars 437 forks source link

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

Open mdedetrich opened 1 year ago

mdedetrich commented 1 year ago

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 https://github.com/sbt/sbt/discussions/7189

muuki88 commented 1 year ago

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

muuki88 commented 1 year ago

From the sbt discussion (https://github.com/sbt/sbt/discussions/7189#discussioncomment-5437221)

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

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.