SIP-46 - Scala CLI as default Scala command

Tooling
16

Coming back to the conversation after some work on the ScalaCLI side I am happy to report that most of the issues were resolved.

  • Users should ultimately have only one tool on their machine. They will still be able to use the “restricted” features via the --power runner argument, so there is no need to have both scala and scala-cli. Related discussion: #351 .

We now have the same behaviour regardless of the name of the binary. Advanced features are only available after --power or after specifying scala config power true

  • The documentation should be updated to reflect that change of perspective: instead of presenting scala as a subset of scala-cli, it would present scala --power as a way to get extra features (with no stability guarantees) over scala. This means that the website should primarily document the stable features, and then have extra sections to cover the --power features. Related issue: #1700 .

We now have a single documentation website with power commands being clearly marked and accompanied by warning sections.

  • The fact that the new runner requires a special shebang command to be used in scripts is an annoying incompatibility with the current runner. Would it be possible to fix it (ie, to remove the need to use shebang)? Related issue: #603 .

The discussion concluded with us still needing the shebang command for scripts. We would otherwise need to change the default command to shebang instead of run, which differs in its syntax from all the other commands and would thus be confusing to users. Shebang will only accept one file/directory as input and the rest will be arguments for the script. For run you can add multiple files and -- separates the program arguments, which allows us to be more flexible with sources. -- is a known pattern used for example in rust.

  • The fact that the new runner differentiates “scripts” from “programs” based on their file extension is an incompatibility with the current runner, and it is also added complexity for the users (who have to reason about .sc vs .scala files). Would it be possible to follow the same approach as with the current Scala 2 runner, which is to fall back to the script mode if there is no “main method” defined in the program? Related discussion #1668 .
  • As a by-product, solving the above issue would also solve the current impossibility of defining a script with no file extension. Related issue: #466

This would require some additional steps (probably double compilation) to determine if something can be treated as a script. We decided against it and instead only when using shebang command we will default to script, so it’s now possible to define a no extension or a custom extension script. That behaviour is also not supported by the old Scala 3 runner.

  • There should be a mechanism to ensure that any “option” that can be supplied via a command-line argument can also be consistently supplied via a “using directive”. There are several possible strategies here, which are discussed in #1524 .

Almost all the options can be both supplied by a using directive as well as in the command line. If there is any that is not available and would make sense to be included in both, we can fix it promptly. I am against having a using directive to use any cmd option since that would make it less obvious for users what is going on. If there is an option from command line that is needed we have to make sure it’s available in using directives.

Let me know if that answered your questions and worries before the next SiP.

As for the current plan for switching to Scala CLI backed scala launcher is as follows:

  1. As soon as the SIP is accepted, switch the scala app in coursier to Scala CLI the same as it’s done when installing scala-experimental and raise PR to change the formula under https://github.com/Homebrew/homebrew-core/blob/master/Formula/scala.rb

These might require changing ScalaCLI version to be compatible with Scala releases (starting with 3.3.0) as the package managers might not update it properly otherwise.

  1. Create or update other possible installation methods which are not currently well supported by Scala:

  • (Windows) SDKMAN, Chocolatey, Scoop

  • (Linux) Apt, Deb, Yum, Rpm, Alpine, Nix, SDKMAN

  • (MacOS) Nix, SDKMAN

5 Likes