Should we keep the old runner under something like scala-legacy, anyone objects to that? Which should be safe to use for run/compiler in the limited capacity.
That simple compiler/runner could well be scala-cli with some command line option, but something like that is needed either within scala-cli or as a separate script.
Ideally, for those cases Scala CLI should work with --server=false, though I think we currently would at least download scala compiler jars. We can add a fallback that searches for compiler jars in local directory, so that we don’t even download the Scala compiler jars.
I would think that the nicest experience would be an --offline flag where any checks for new versions and such are omitted (just use what you’ve got), and where instead of downloading a missing critical dependency, you get an error message saying exactly what you would have tried to download if only you had not been offline.
Thanks for the update on what is coming! Scala CLI is indeed really valuable, esp. to beginners!
Yes, I think it is good if the old runner can be executed under some different name such as scala-legacy or scala-old-runner or similar that is self-explanatory. It is good if it is installed under a name starting with scala- so that it is discoverable using tab completion. People can then make alias to it if they wish.
I also think it is important that cs keep installing the scala-cli runner also under the name scala-cli when doing a scala install from the official install page, so that documents written assuming that cs has installed scala-cli still works for a long while. (For instance, I will send hundreds of books to print on paper soon relying on the scala-cli runner installed by cs and I guess more teachers are in my situation as the fall semester is approaching…)
Also, I think if users install Scala CLI from its home page I think they should get the runner (also) under the name scala-cli as I guess many have written instructions relating to the Scala CLI home page: Install Scala CLI | Scala CLI
I’ve been enjoying scala-cli for convenience of trying out bug reports. Much nicer than creating an sbt project!
In addition, Scala 2 tests recognize //> using options and Scala 3 has a ticket for it.
Until now, Scala 2 tests have used // scalac: -options syntax.
I did not realize that syntax was introduced ten years ago. Another missed anniversary.
However, the other day while using scala-cli casually, I got the weird “can’t start compilation server” or whatever, “use clean”, which also didn’t work. So I’m a bit set back in my total embrace.
Scala 2 REPL used to have a server mode, fsc, that was always breaking and eventually deprecated. I think the “no compilation daemon” option -nc became the default, but maybe you can still ask for -nc:false. That was the source of many headaches.
I hope scala-cli has a mode which is no-server, no-downloads, just give me a basic REPL that reflects “what the batch compiler would do”, to the best of its ability. As usual, any friction in this basic function is problematic.
Also, Bjorn, thanks for your other post where you note that ampersand is a fish. As a Pisces, I’m embarrassed to say that escaped me until now. (Edit: I neglected to pun on && and Pisces, except one ampersand should be upside-down.)
So, for anything larger we actually wanted to incorporate most of the Scala CLI components into another build tool such as bleep, which would not accept any inline comments, but we are not able currently to work on that. We will want to get back to this as soon as ScalaCLI backlog clears up a little.
We can for sure add an option to show an error when using directives in multiple files for the time being. And in the future that could be turned into a default error with automatic migration to the previously mentioned build tool.
As for the offline mode, we are working on it in context of adding Scala CLI to the Scala 3 releases. We want to have at least basic commands such as repl, run and command to not need to download anything if you use the specific Scala version. This will not be possible for everything right not because there is just too many possible configuration options.
