Implement Scala CLI as the `scala` runner command

[Gedochao]

Finally, the time has come to bring SIP-46 to a closure and implement Scala CLI as the official runner command for the Scala 3 compiler.

Corresponding compiler issue

• https://github.com/scala/scala3/issues/20098

Relevant docs

• SIP-46 details
• experimental Scala CLI as scala installation
• migration from the old Scala runner (a guide)

Requirements

• [x] set up downloading of Scala CLI JVM launcher from GitHub VirtusLab/scala-cli
• [x] download library dependencies to the dist/target/pack in maven repo style
• [x] fix scripts to wrap Scala CLI launcher, setting both the local repo and default scala version launcher options
  • [x] update for windows (batch)
  • [x] update for linux/mac (bash)
• [x] run any existing legacy (old) scala runner tests against the Scala CLI launcher on the scala/scala3 CI
• [x] use the Scala CLI launcher instead of the scala runner in official Scala 3 distributions
  • [x] coursier
  • [x] brew
  • [x] SDKMAN

Potential follow-ups which are NOT included in this issue's scope

• including platform-specific native installations of Scala CLI in Scala 3 official distribution channels
  • this should be done alongside native distribution of scalac, scaladoc etc
• including Scala CLI in other Scala 3 installation methods (APT, winget, etc)

[bjornregnell]

• including Scala CLI in other Scala 3 installation methods (APT, winget, etc)

I think allowing a great Windows experience will help a lot. A vast majority of students coming to Lund University to learn Computer Science have windows laptops. I think making the new scala available as an .msi as well as using winget and choco is the way to go if I should judge from how my 150+ students last fall with windows would like to install it.

Allowing apt (or snap --classic) will also help those with WSL2 but WSL-users are still a minority among beginner learners compared to "normal" Windows using Windows Terminal with powershell or cmd. Anayway i recommend students to use sdkman under WSL.

My priority order as a teacher of Scala as the fall semester of 2024 is approaching: .msi, winget, choco, sdk, apt, snap

[Gedochao]

@bjornregnell don't get me wrong, having native platform installations for Scala CLI is the plan, but we want to do it in steps. I was merely establishing the scope to be covered in this ticket, so that we don't try to do everything all at once.

As Scala CLI will be distributed alongside the compiler, we would need to have all the scripts contained in the installation in sync. scalac, scaladoc, scalap... everything should get native packages and then get distributed as such on the correct platforms in the future.

For now, the Windows native distribution will still be available through the old installation methods of scala-cli. We won't be sunsetting those for the time (if at all).

[bjornregnell]

having native platform installations for Scala CLI is the plan

Great! I also think it is really good if the scala-cli home page makes the soon "old" scala-cli still to be easily installable under that executable name for all those who are stuck on old Scala versions, so they can use their old scala runner together with scala-cli. (Although beginner cs students rarely come with any Scala on their machine.)

Even if professional devs most often use some kind of Linux, I believe a vast majority of beginner students in cs at universities come with Windows 10/11 on their laptops, and they might not be seasoned in tricky install procedures of java+scala. So making the Windows UX top-notch for beginners is important IMHO.

If we can make it a one-click-install-everything on Windows with an -msi (perhaps it can check for and also install a JDK if needed?) students will be happy. (Most hard troubles I seen on students' machines is them having e.g. corrupted or no JAVAHOME, multiple conflicting JDK versions, an old Oracle entry in the registry incompatible with their User Path etc etc and they have no clue why it does not "just work"...).

[bishabosha]

@kasiaMarek @tgodzik do you know how the special name handling for scala-experimental works in error messages? (so the command name renders as scala not scala-cli)

currently our solution of bash script wrapper of java --jar scala-cli.jar is rendering the command in error message as scala-cli, e.g.

dist/target/pack/bin/scala foo
[error]  foo is not a scala-cli sub-command and it is not a valid path to an input file or directory.
Try viewing the relevant help to see the list of available sub-commands and options.
  scala-cli --help

[tgodzik]

I think that might be hardcoded, we might need to change that.

[bishabosha]

I think that might be hardcoded, we might need to change that.

@tgodzik @kasiaMarek

https://github.com/VirtusLab/scala-cli/blob/9a7fda1809808b2307e5092f3367769c7f7dcaa2/modules/cli/src/main/scala/scala/cli/ScalaCli.scala#L30-L38

yeah it looks unavoidable- (new Argv0).get("scala-cli") will always return "scala-cli" on JVM - only native launchers override Argv0

it would be good to have a way to change the name to "scala" on JVM

[hamzaremmal]

@Gedochao Should we close this now that 3.5.0 is in Maven Central ?

[Gedochao]

@Gedochao Should we close this now that 3.5.0 is in Maven Central ?

Yes, we should!