Use scl or scala instead of the cumbersome scala-cli

[bjornregnell]

(Initially also an issue here, although better to keep discussions in this thread.)

It might be good to have both simple official binaries scala and the versatile scala-cli in terminal, but scala-cli is verbose and clunky so suggesting scl as a shorter command, while keeping scala-cli as the name of the service (cf. sdkman and sdk).

Or else we could consolidate scala-cli and scala and possibly also cs into one single scala command.

[bjornregnell]

IMHO this can be more important than you might think at first sight. I find scala-cli clunky even with completion in terminal. After trying sclas an alias I love it - and I can still have the official scala even if now scl is shorter and can do more as a true "better scala" should be :)

Why can't those that want scl just do the alias dance? I believe it will not happen for most. It's what comes included that goes, especially for a beginner...

And it is now, when scala-cli is not yet wide-spread that we can do this without too much turbulence...

[bjornregnell]

Also, we might want to have an increasing user base before scala-cli might become the official scala runner. If scl gets a momentum we might never need to replace scala with scala cli and thereby no need to break all stuff that depends on the official scala compiler behavior...

[romanowski]

We picked scala-cli intentionally, as a temporary name for the tool. I am personally like scl but we will leave the decision for the SIP committee to decide about the name.

My recommendation would be that scala-cli should become scala with an alias to scl.

[bjornregnell]

That would be cool. One obstacle might be all the legacy stuff out there assuming the old behavior of the scala command on path. So if scala-cli becomes scl it would mean that the old and new can co-exists for as long as Cobol as been on planet earth 😄 and things will not break.

[romanowski]

scala is just a repl, is that that many tools that starts repl? scalac is different story and even with Scala CLI we should keep it around.

We are thinking what running justscala-cli should do: now we print help but we can start repl, similar to what scala does now.

[bjornregnell]

scala is just a repl,

Well, it is also a runner that put stuff on your classpath and calls java. The scala-script is pretty elaborate including options. But I'm not sure how many scripts out there that invoke/assume old scala. For me that "breakage" is acceptable. I like that a beginner gets the help-banner whith no args, esp as the new . arg means something new compared to old scala. I kinda like scl repl as it is explicit, albeit a bit more cumbersome than just scl. This is a trade-off between discoverability (with the help banner you get to see what you can do) and convenience of the most common use case (unclear what that is to me, depending on who you are...)

[SethTisue]

My recommendation would be that scala-cli should become scala with an alias to scl

What would happen to Scala 2's scala? cc @lrytz

[bjornregnell]

Aha, I see. Thanks for encouraging words @som-snytt !

what a hassle

Yes, and more often than we think optimization of beginner UX is also relevant to power users. The acronym cli says nothing to many of this planet's inhabitants and the dash in the name requires an extra press on tab for completion, and as the command will be written a hundred times a day or more, this will wear down patience. If this really promising new beginner-friendly Swiss-army-knife-runner ❤️ can't be named scala because of clashes with the soon-to-be-legacy good-old scala-runner, then IMHO scl is short enough (it's a pity that someone already has stolen sc and that crime might not be statute-barred any time soon 😄 ).

[som-snytt]

I was going to say on another thread that scali sounds like a Swiss diminutive. Your invocation of the Swiss army knife, and I have such a tool on the desk in front of me which I use several times a day, suggests the association is apropos.

[bjornregnell]

🇨🇭

[julienrf]

I think this is an important point. Currently, it is possible to install a scala command-line program that is completely different from the scala-cli app. It means that users might end up with two programs named scala on their system, and they might get confused. Typically, if someone installs “Scala” with cs setup, they get a scala command-line program. If the same people also install scala-cli, then which scala program will be picked?

I do believe keeping cs setup as an installation step makes sense because it checks that you have a JDK, and it also installs sbt in addition to the scala command-line program (and other command-line programs).

If we tell people to just install scala-cli, then they will have to learn yet another way to install a build tool, when they will arrive at a point where they want one.

Also, currently cs install scala:3.1.1 does install the scala interpreter for Scala 3.1.1. If scala gets replaced with scala-cli, that command will not make sense anymore.

[bjornregnell]

@julienrf Well, having several things 1) scala 2) cs 3) scala-cli is confusing to beginners. I'd be fine with the proposal by @lrytz to consolidate all this to a versatile scala command that can do everything that the old scala and then new scala-cli and cs can do. The differentiation into these three tools is only for historical reasons, but a newcomer doesn't care about history...

We are thinking what running just scala-cli should do: now we print help but we can start repl, similar to what scala does now.

@romanowski I think we oldies can live with a new versatile scala embedding both scala-cli and cs abilities as long as running it without any args just starts the repl.

[bjornregnell]

@romanowski Any more info on this? I'm just starting to update my teaching material in preparation for the coming fall semester, and any hints or guesses where this is going would be valuable :)

Also the current getting-started page sends visitors to the coursier homepage which is not very easy for a beginner without terminal knowledge (how do I open a "terminal" on my "platform", and what is it even?). I'd love to start my fall semester with a consolidated beginner UX experience of both home page and runner, if that might be in the road-map for potential release until then? (Settling on names of stuff ready for the fall semester might be a suitable goal as many teachers starts beginner education at that point in time...)

[julienrf]

After discussing with the SIP Committee, we concluded that it would be better for the users to only have one tool installed on their system: scala. Since the “restricted” features can still be available via the runner argument --power, there is no need to have both scala and scala-cli.

[tgodzik]

I think we for now we can install both tools and as soon as we stop using the old launcher we can also remove scala-cli, so that the users that don't use the experimental launcher can still get scala-cli out of the box.

[SethTisue]

maybe --extended?

[bjornregnell]

Yeah --extended or similar is better, I think; it's good to find an alternative to --power as that is a bit cryptic.

[julienrf]

Do we really need those three levels? I think two levels should be enough.

[Gedochao]

long term, yes, we want to have 2 levels in the future, when everything that's considered stable is part of scala. (merging sip-mode and restricted/stable).
For now, however, many users rely on the scala-cli installation, so this division remains useful.
Once we're past the implementation phase and Scala CLI truly becomes the new scala command, we'll be able to go down to 2 levels.

[bjornregnell]

I think it makes sense to have a "grace period" where "old" scala-cli continue to work, while then "new" scala is being rolled out.

@Gedochao For how long do you think such a grace period with "redundnat" runners is needed? Could you have two levels, unlocked by --experimental on the new scala during such a grace period?

[Gedochao]

I mean, I believe we'll need to keep the scala-cli installation for at the very least until the end of the implementation phase (by which I mean the time when we'll be ready to install Scala CLI as scala as part of the main ways of installing the language rather than the current temporary solutions). Not sure if we're ready to give an estimate for it, we're still getting new SIP-related tickets.

And then, I would guess even then we might not be getting rid of the scala-cli installation for a couple releases, until we're confident it's no longer needed... I guess it hasn't really been discussed yet, so it's tough to say.

Until then, using the --experimental flag as an alias (or instead of) --power gives me a bit of a bitter taste.
I mean, looking at the following syntax:

scala --experimental package .

That kind of implies that the package sub-command is an experimental, non-production ready feature, while in fact we consider it stable and it's been widely used by scala-cli users for a while now - it's just that it hasn't been included in the SIP. Simultanously, I have no quarrel with using it with the --power flag, implying it's a power user feature that requires some knowledge to use.

...but yeah, the TL;DR of it is that these concern will become a lot less relevant once we're past the implementation phase.

[bjornregnell]

I now see your point about the downside of --experimental. I'm fine with --power if we can't find something better.