These are chat archives for sbt/sbt-native-packager

29th
Jan 2016
nafg
@nafg
Jan 29 2016 00:50
@alkersan @muuki88 I guess sbt-native-packager doesn't have good support for multiple service config files, I guess that would be a desirable enhancement
Nepomuk Seiler
@muuki88
Jan 29 2016 09:03

IMHO this is out of scope for sbt-native-packager. Generalizing over how you configure you different environments depends heavily on your use case.
You can go from config files, env-variables over cmd-line parameters to automation tools like puppet/chef.

SBT's support for multiple modules lets you solve the "different package types" very elegantly and without any sbt-related confusions (really, Scopes/Configs
are counter-intuitive even if you have used them a couple of times ). And they don't require much configuration.

nafg
@nafg
Jan 29 2016 09:17
@muuki88 why is it out of scope? If I understand correctly, sbt-native-packager provides the ability to generate and include upstart files and systemd files, however, if I'm understanding correctly, it's somewhat either/or. Is that not the case?
If it is the case, it's a restriction imposed by its design, is it not?
And it's not a desirable restriction is it?
For example Docker's package includes both
Dmytro Aleksandrov
@alkersan
Jan 29 2016 09:51
@muuki88 I tend agree with @nafg . I think the submodule-per-package approach is feasible when really heavy customizations are needed. But necessity to support multiple service-loaders is just what we have today: lots of organizations run Ubuntu servers for example and Ubuntu is in transition between init systems.
Nepomuk Seiler
@muuki88
Jan 29 2016 10:43

I understand your pain and we try really hard to make the usage-experience as smooth as possible.
My concern is, that generalizing this configuration stuff will make the code base a lot more complex and harder to maintain.
SBT is a sophisticated build tool. Adding complexity makes it even more harder to reason what's going on. IMHO subprojects
are a simple, easy to grasp concept ( most build tools have it, and things-depending-on-things is a devs daily business ) and they are
easy to configure with

lazy val app = project("app")
  .settings()

lazy val ubuntuTrusty = project(file(".ubuntu-trusty")
  .enablePlugins(JavaServerAppPackaging)
  .settings(
     systemLoader in Debian := Upstart
  )
  .dependOn(app)

lazy val ubuntuVivid = project(file(".ubuntu-trusty")
  .enablePlugins(JavaServerAppPackaging)
  .settings(
     systemLoader in Debian := SystemD
  )
  .dependOn(app)

Now you can call

ubuntuTrusty/debian:packageBin
ubuntuVivid/debian:packageBin

and you will get you packages configured as needed. On your way you can add more
and more customization if needed.

In short, adding things to generalize over configs is hard to do (I actually have no
initial idea on how to do this), harder to debug for a, IMHO, little gain.

What would you expect the API to look like, if we would decide to implement this?

Dmytro Aleksandrov
@alkersan
Jan 29 2016 11:53
@muuki88 i've tried both approaches. At first I've made 2 separate packages (not with submodules, but with sbt Commands) and now I've made single package but with 2 service loaders bundled inside. Now I feel that my initial intent was not what I needed. This is what I have now:
lazy val packagingSettings: Seq[Setting[_]] = Seq(
  //
  //... other required debian settings
  //
   linuxMakeStartScript in Debian := None,
   linuxPackageMappings <++= (packageName, sourceDirectory, target in Universal, linuxScriptReplacements in Debian) map startScriptMapping(Upstart),
   linuxPackageMappings <++= (packageName, sourceDirectory, target in Universal, linuxScriptReplacements in Debian) map startScriptMapping(Systemd)
)
startScriptMapping is a helper function I had to pull up from JavaServerAppPackaging internals
Dmytro Aleksandrov
@alkersan
Jan 29 2016 12:07
@muuki88 but I understand your concerns. It's not resposibility of native-packager to match everyone's operatonal environment by default
Dmytro Aleksandrov
@alkersan
Jan 29 2016 12:12
@muuki88 and I see if make systemLoader a Seq- then it becomes tricky to generate pre/post actions in maintainerScripts
Nepomuk Seiler
@muuki88
Jan 29 2016 13:11

Hm. I like your approach. This way you would only have to build one jar. And you could choose your systemloader based on any task you want.
Making startScriptMapping available from the outside would make this a lot easier, right?

If you make a pull request, adding the method to a new autoImport object in https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaServerApplication.scala and add the necessary documentation, we could surely add this.

Dmytro Aleksandrov
@alkersan
Jan 29 2016 14:06
@muuki88 ok
Dmytro Aleksandrov
@alkersan
Jan 29 2016 21:39
I'm looking at DebianDeployPlugin. As I see - it's only capable of publishing *.deb package to servers like nexus and artiifactory with maven/ivy layout repos, right?
Dmytro Aleksandrov
@alkersan
Jan 29 2016 21:48
is there any interest or plans in adding deployment to servers like Aptly and Artifactory (into Deb repos)
Nepomuk Seiler
@muuki88
Jan 29 2016 21:49
Yes. If you need to push to a Debian repo ( like reprep ?) you need external tooling. Or you use the commercial nexus / artifactory versions, which IIRC have Debian support
Dmytro Aleksandrov
@alkersan
Jan 29 2016 21:56
@muuki88 I've just made publishing to artifactory apt repo and it looks not too complex. https://gist.github.com/alkersan/967251e32607b86e6532
Nepomuk Seiler
@muuki88
Jan 29 2016 23:29
Nice! This looks pretty good. Is apt accessible in the non commercial version?
I can imagine this in tthe native packager code base or in a separate plugin. If you submit a PR fit native-packager, we have to see which http library to use ( we recently tried to reduce dependencies )