Coursier: Use sbt's launcher, for now

[dwijnand]

While I think, long-term, it would be excellent to kill off sbt/launcher, I'm concerned that it's still premature and over-reaching to do so right now.

As such, I recommend that, instead of cs setup installing a bootstrap around coursier/sbt-launcher, it just bootstraps https://repo1.maven.org/maven2/org/scala-sbt/sbt-launch/, even if that means that the process will resolve sbt (https://repo1.maven.org/maven2/org/scala-sbt/sbt/), and its internal and external dependencies, with old-man Apache Ivy.

(Whether that means changing https://github.com/coursier/apps/blob/master/apps/resources/sbt-launcher.json or creating a new descriptor, I'm not sure.)

AFAICT, there are 3 parts that cs setup impacts:

1. build-time packaging (sbt "preloads" the bundles with the dependencies, and copies them during on first run)
2. the "runner" part (before java), which does the preloading stuff above, and -D, -J support, etc (sbt/sbt-launcher-package vs paulp/sbt-extras)
3. the "launcher" part (on the JVM), where sbt is just an "app", with the complicated setup it has (components, locks, "installing" components, ScriptMain, etc).

This issue suggests deferring changing that last part to later.

For the first issue, I've always been sceptical of the preloading business, but we must, nonetheless, try not to regress, particularly for users behind corporate firewalls, the Great Firewall of China or the Great Barrier Reef (high latency).

For the second part, we already have unfortunate divergence with the history behind the two. But I also think it's a much simpler problem to solve than the legacy behind sbt/launcher's logic.

[alexarchambault]

I wasn't aware that cs launch org.scala-sbt:sbt-launch:1.3.10 basically works… Not sure what are the limitations of using just that. Beyond it using Ivy to fetch sbt, and not reading things like .sbtopts I guess.

The original reason I settled with coursier/sbt-launcher is that I knew I can launch it like any other JVM application, with cs launch or via an app descriptor.

[alexarchambault]

About the 3 points you're mentioning, for 1., it should be do-able to populate the coursier cache from an archive. The right archive would need to be generated upfront, and it'd be safer to unpack it manually, so that we don't accidentally overwrite existing files in cache, or write wrong cache metadata alongside existing files.

About 2., my hope was to get a native executable for coursier/sbt-launcher at some point, along the lines of https://github.com/sbt/sbt/issues/5406. cs install / cs setup can install and update such native launchers. As a native app, the launcher would issue the java … command itself, so it could support .jvmopts and the like, just like sbt-extras does.

About 3., I'd like to have coursier/sbt-launcher be closer to sbt-launch. It should stop adding sbt-lm-coursier itself, be fine with a missing project/build.properties, support sbt new, … These things just need to be fixed.

[dwijnand]

These things just need to be fixed.

Speaking of in the short term, would you be happy to defer this, then? I.e. take this variable out of the cs setup proposal?

[alexarchambault]

It could be deferred, I'm just fearing org.scala-sbt:sbt-launch isn't featureful enough out-of-the-box. It doesn't accept any of the sbt-extras options for example, unlike coursier/sbt-launcher, which supports some of them (like -D and -no-colors).

[dwijnand]

Ah, ok, so what do you think of this plan:

1. Separate out the part of coursier/sbt-launcher that ports the subset of sbt-extras' logic that can be run inside the JVM (A) from the part which is a port of sbt/launcher (B).
2. Publish A and use that as the descriptor's target (deferring the rest, B, for later)

?

Also, what's the difference between running coursier/sbt-extras and running cs setup's sbt?

[alexarchambault]

Ah, ok, so what do you think of this plan:

That could work. That's a good idea! I'll try to find some time for it.

Also, what's the difference between running coursier/sbt-extras and running cs setup's sbt?

coursier/sbt-extras handles all the arguments of sbt-extras, including -batch or reading .jvmopts. The one installed by cs setup only handles those around here.

coursier/sbt-extras actually downloads and launches the same kind of JAR as the one that cs setup installs. The former is generated by this script (so it's a coursier "bootstrap") then pushed as a github release asset, while cs setup creates that bootstrap itself from an app descriptor. So when using coursier/sbt-extras, the options are actually processed twice: once by the bash script, then again by the logic in the main class of coursier/sbt-launcher.

[dwijnand]

That's a good idea! I'll try to find some time for it.

Thanks. I'm also asking because I want to do the same by porting dwijnand/scala-runners to Scala (or Java, if necessary), using an API-stable programmatic equivalent of cs launch, and then native-image that.