sbt-davenverse and sbt-spiewak wedding

[rossabaker]

I just unarchived this repository, which I had forgotten existed.

We have two good build plugins, sbt-spiewak and sbt-davenverse. They both do about the same thing, and they're both good. My hopes for this project:

1. Identify anything uniquely good about sbt-spiewak and sbt-davenverse (e.g., docs support).
2. Identify and resolve any conflicts in approach between the two. I don't think there are many.
3. Replace the contents of this repo with the fruits of 1 and 2.
4. Make sure it's well-integrated with a g8 template. sbt-davenverse already plays nicely with library.g8.
5. Be open to extension for projects that insist on being different. I think the nature of SBT mostly takes care of this.
6. Not end up like that xkcd cartoon about standards. Always a risk.
7. Have multiple maintainers. sbt-spiewak has a bus factor of 1, and I think sbt-davenverse has a factor of 3.

If adopted widely, it will reduce cognitive overhead for maintainers as we flit from project to project, and reduce the size of many of the builds.

Out of scope is specifying stacks of versions. Last time I tried that, everyone hated me and said mean things, several of which were deserved.

@softinio is volunteering to help on our builds, so I've invited him to this project. I ran this basic idea with @djspiewak and @ChristopherDavenport, who authored the originals. @armanbilge offered support for the concept elsewhere.

Discuss.

[djspiewak]

To me, the most important elements of sbt-spiewak are as follows:

• The version scheme (including baseVersion)
• Prescribing sbt-gpg (since sbt-pgp honestly just doesn't work correctly)
• The mima integration (most of which follows from the version scheme)
• Correct out-of-the-box defaults for build (including scalac sane-mode), release, and github actions
  • A release task that doesn't rely on commands and other magically stateful sbt things
• Correct default configurations for console and ScalaJS (doc, etc)
• The fact that scala-steward understands it

I think that's mostly it? I think both local releases and CI releases are important capabilities, and IMO both should be supported in a first-class way. I don't care much what the defaults are so long as they're easily adjusted. I would also like support for source dependencies, probably similar to what's in sbt-precog, since that's often useful when doing development in a polyrepo setup.

[djspiewak]

Sbt-pgp interacts incorrectly with the gpg command and ties itself to an insecure model due to the bouncycastle mode. Among other things, this makes it impossible to use split subkeys, which makes this a hard line requirement for me (since my keys are thus split). The fact that it allows you to pass in gpg passwords is somewhat meaningless since it doesn't change the security model, which is why sbt-gpg just doesn't bother. I get that everything involving GPG is a pain in the ass, but at the same time, it's a single command to export a private key without a password, and you only have to do it once. That seems a small price to pay for a plugin which uses gpg in its most secure and updated mode.

Regarding mima, that's definitely something we'll have to be careful about. I think if I were doing sbt-spiewak again I would probably rely more on the versionScheme setting, which prescribes exactly the correct mima choices. More importantly though, having a mechanism to filter out versions is important for libraries that introduce new modules, which is not uncommon.

I'm definitely not averse to delegating to sbt-tpolecat. The reason I didn't is it falls behind milestone and RC versions of the compiler when new flags are introduced. This was most severe in 2.13, when the whole partial unification juggle got complicated. I'm still a bit leery of that era, though I have an open mind. The composability advantage of the standard solution is not to be undervalued.

[armanbilge]

though I have an open mind

ménage à trois? 😆

[rossabaker]

I'm currently fux0r3d by a "cannot allocate memory" error that's fixed in sbt-pgp and can't cut a security release. I'm concerned about depending on what appears to be an unmaintained plugin vs. the mainstream one. I wonder if there's anything that can be done to fix the issues in the main one.

[djspiewak]

I'm actually a maintainer on both. The only reason sbt-gpg hasn't released anything new is because there haven't been any obvious needs. I can port the serial signing change though and make a release.

I wonder if there's anything that can be done to fix the issues in the main one.

I did some work on this a while back. The main one is unfixable without dramatic breaking changes. Those breaking changes are totally possible… but you basically end up with sbt-gpg if you do that. I was originally going to propose the breaking changes and then sbt-gpg popped up so I didn't bother.

[rossabaker]

Alright. Morning wasted, but concern withdrawn if someone is keeping it alive.