SIP-46 - Scala CLI as default Scala command

Tooling
48

I think as the main way of installing Scala we can keep coursier. This is our main package manager and it should install scala-cli as scala when doing setup. We should really think of it as a separate package manager and we have the most control over it.

For any other package manager we just install Scala CLI and let that specific package manager manage updates etc. I don’t believe we 100% need to install sbt everywhere and every time.

2 Likes
49

I think we can treat scala-cli as GitHub - rust-lang/cargo: The Rust package manager
and for the version, how about:

scala-cli 3.3.0.2023-04-01-stable which comes with the same release date of scala3.3.0
scala-cli 3.3.0.2023-05-01-stable with bugfix or feature update before scala 3.3.1

and scala-cli 3.3.1.2023-10-01-stable will come alone with scala 3.3.1

And a scala-cli can update itself to a newer version

1 Like
50

There are different ways of installing (I use sdkman on my various ubuntu boxes), but we need a single official way that works on all platforms. Windows is probably the most spread platform on desktop dev machines (among cs beginner students Windows prevail because of gaming until they later transfer to Linux and game less because they code more :slight_smile: ).

Neither brew nor sdkman is good for vanilla Windows so we need something official that work for non WSL-based users, as well as macos (intel+arm), linux (debian-based or not…). As I understand it, cs is the only feasible/available option for that?

2 Likes
51

For “standard” package manager for Windows you may want to consider Chocolatey. From Wikipedia description:

“Chocolatey is a machine-level, command-line package manager and installer for software on Microsoft Windows. It uses the NuGet packaging infrastructure and Windows PowerShell to simplify the process of downloading and installing software.”

I am not associated with Chocolatey, but I do use them to manage software installations on Windows, for instance this the way I install SBT. For me it is an equivalent of brew on Mac and apt on Linux.

1 Like
52

Yes, so there is a strategic decision to be made if to support all de-facto standard package managers with the costs associated with that. I agree that sdkman, brew, apt, rpm and chocolatey seems a reasonable set to have expectations on to be supported, but it is perhaps even more important to enable a one-click install from the official scala download page on all platforms and coursier provides that with a cross-platform experience, and other package managers are platform specific.

A platform-specific package manager is yet another thing for a beginner to grok and I would like to avoid to have to explain that conditional to all platforms, when a beginner could just do a one-click install if possible. (But it is of course nice that everyone can use their favorite package manager given that there are resources enough to keep all different package up to date in each release cycle…)

1 Like
53

I would much more prefer if it was just another thing cs managed. That way I don’t need to deal with yet another package manager. Chocolatey might be nice if all your other tools already support it and are installed through it, but if they are not, now you just have more headache as Chocolatey might install things indirectly which you didn’t expect which gets preferred before what you had installed manually.

1 Like
54

We are currently going with 1.0.0-RC as it’s the safest release number we can use. If some packages updates turn out to be impossible to update we will be able to get back to the earlier ideas as it’s easier to bump to 3.x or more in this case.

As for package managers I feel like cs should still be recommended (with Scala CLI as Scala) as any other solution will differ between OS. However, we should still allow users use different package managers if they want to and as part of that effort we will work on releasing Scala CLI as Scala for any package managers currently supported as seen here Install Scala CLI | Scala CLI

We don’t plan currently to make sbt installed together with Scala CLI via coursier. If needed it would be better to just depend on a separate sbt package and follow standard practises of a specific package manager.

4 Likes
55

Do you intend to keep shipping the scala-cli command as well, or have it only be scala?

and if so when should the user use one over the other?

56

We don’t indent to keep scala-cli separate once the roll out is complete. They currently behave in the exact same way so it would be redundant.

2 Likes
57

SIP-46 - Scala CLI as default Scala command says

We propose to replace current script that is installed as scala with Scala CLI - a batteries included tool to interact with Scala. Scala CLI brings all the features that the commands above provide and expand them with incremental compilation, dependency management, packaging and much more.

This is now an accepted SIP, so if we’re reading the spirit of the SIP, I am guessing the way to go is to fold Scala CLI as scala command as version 3.3.0, implementing sbt-like functionality into the default CLI command with more batteries included.

However, I also agree that it might lead to deeper confusions.

  • If using is not part of the Scala language specification, and basically whatever-Scala-CLI-implements at the time, that can quickly lead to using X works with Scala version 3.4.0, but not 3.2.0, and someone else would say “oh just use Scala 3.4.0 but with Scala version 3.2.0”
  • using doesn’t translate over to other build tools like sbt, Mill, Bazel, Gradle etc, even though it’s now part of “Scala”.
  • using would be different from one machine to another, because depending on the brew means that people could have different CLI installed on the machine? That’s sort of the situation with Bash and Python, but that would be a wrong lesson to learn IMO.
1 Like
58

Regarding the points of potential confusion:

  • the first point demonstrates really well what’s the downside of using a single name Scala for both the runner and the language; it’d provide a good case for keeping the version of the runner independent (even if the runner is shipped with the Scala package). How quickly could we run into this problem remains to be seen, it’ll likely depend on the development of useful new directives. But any time it happens, it will be too soon, we ideally plan ahead. How about adding a new command which would freeze the script’s requirements into “//> using runner 1.1”? The runner could use it to decide if to run the script.
  • the lack of support of directives in the build tools might not be a big problem as long all documentation makes it very clear that they are only for the runner. The old Scala runner also featured some custom commands that do not exist in Scala (although they are not in the source code). The block-comment prefix should ideally communicate that they are not part of the language.
  • the “works on my machine” problem is indeed likely to occur should the runner be getting some attractive new directives over time. Yet maybe it could be alleviated a bit by the freeze command (I suggested above). The problem might not have a big impact though, provided that the set of directives would remain stable. Then the freeze command might pin the version of the runner to the oldest version which supports given set of directives used.
59

I think a single warning explaining that this using directive is not available in the current version would suffice in most cases. We just need to explain to the users what they need to do in case of any issues. Any errors we give out need to be “actionable”.

Also, I don’t think we will add any core directives any time soon and anything less prominent might never come up when copying scripts between users.

60

That’s the thing, a warning might be okay for a non-essential directive but if the script’s correctness would rely on it, then an (actionable) hard-stop error would be much more preferred over trying to run a semi-broken script, which might fail in a complicated way.

I also don’t think that any core directives are coming, but sometimes it’s hard to predict the future.
Right now it seems that the core directive set is stable (like the set of commands available in the old Scala runner), but one can’t tell for sure.

61

I am using scoop on windows.

62

Yes, most developer is using Windows including me and we can add a help guide for ChromeBook too.

63

I think the current //> using ... is not that clear as //>import dep:... or something like //>import url:... , //>import git:... and //>import mvn:...

64

I think the discussion about what installation methods we recommend to newcomers is valuable, but it’s also mostly orthogonal to Scala CLI and to the SIP. Regardless, I’d like to state my opinions.

I doubt our ability as an organization to maintain an entire package manager. Coursier is a one-person project that encompasses both a dependency manager and a package manager. The dependency management aspect is a big and undermaintained project unto itself…!

On MacOS and Linux, I see little value in having yet another package manager. I personally have stopped using cs at all on these OSs. I’d much rather use a standard, robust package manager that I’m already familiar with, such as Homebrew, to install Scala CLI and sbt. And I’d much rather manage my JDKs some standard way, too.

Now that scala-cli can do things like run scalafmt and scalafix, the package management aspect of Coursier no longer provides any value for me. (It certainly doesn’t provide value in proportion to the amount of development effort needed to maintain it, going forward.)

On Windows, sadly, the question is more complicated. cs setup has real value there. Perhaps we should retire the cross-platform package management aspect of Coursier and concentrate on providing a Windows-only tool that does the equivalent of cs setup.

6 Likes
65

For a long time I wasn’t sure what I thought. After reviewing the discussions above, I now agree that keeping the Scala CLI version numbering separate is best.

2 Likes
66

We found a number of issues in 1.0.0-RC1 so we will be releasing another one before working on the package managers.

2 Likes
67

(Or perhaps scratch “Windows-only” from that — the core of the suggestion is to handle initial setup only, rather than ongoing package management.)