(The Scala Center team is dedicated to providing regular and transparent community updates about project plans & progress we develop or support. In this forum we created a new topic category to allow quicker orientation going forward: “Scala Center Updates”. Even though all feedback is welcome, we keep the right to make executive decisions about projects we lead. Overview of all our activities can always be found at https://scala.epfl.ch/records.html)
There’s no clear way to setup one’s machine for Scala development. Installing an Oracle JVM has become more and more blurry over the years, and each Scala CLI tool has its own installation process. Instructions to install JVMs and those Scala tools also vary depending on your operating system.
To address that, the Scala Center decided to invest in the install command of coursier and to pack it with JVM installation capabilities. The ability to:
install applications,
install JVMs,
do that from a native application, generated with GraalVM native-image,
give us the possibility to have a standalone CLI tool to setup one’s machine for Scala development, that doesn’t need a prior JVM to be installed.
Going forward
Your feedback about this new setup is very welcome. Our hope is to make this setup the default way of installing Scala on one’s machine.
This sounds like it would be awesome for the educational space. Getting students setup up and ready to work in Scala is always a challenge early in the semester and it can both slow down and turn off many students.
I’ve been using this new distribution on 3 different Windows machines for a couple months, now, and I can say that it is immensely better than anything we’ve ever had before. It’s such a breeze to install sbt and the Scala CLI so easily.
I’m particularly fan of the --jvm x option which allows to easily launch one of the projects using a different JVM, for example
$ cs launch --jvm 11 sbt
On Linux it’s relatively easy to work with separate JVMs, but on Windows this was annoyingly tricky before cs.
Incidentally, do you think it would make sense to publish coursier on the new window package manager repository (https://github.com/microsoft/winget-pkgs) ? That way eventually a full setup could be reduced to two commands on windows without needing to download anything manually:
Easy installation is very important indeed. But if we want to get users hooked on Scala before they are even required to do anything else, we can actively support free web-based platforms that use Ecplise Che or Eclipse Theia with the Metals plugin. Unfortunately the current support is clunky at best.
Metals was recently added to the Eclipse Che plugin repository, but the current method where Metals downloads itself (even when cached), bloop and other dependencies suffers from random timeouts and errors. https://che.openshift.io/dashboard/
Additionally, Scala currently doesn’t have a template for easy start like many other languages. https://che.openshift.io/dashboard/#/getstarted?tab=getStarted
Actually on Windows you can just double-click on the installer executable (or confirm execution when you download it from your browser). That’s how Windows users install stuff. They don’t know to use a complicated incantation on the command line. Edit: It is not idiomatic to use a complicated incantation on the command line, and Windows users can find that suspicious.
To be clear: I include myself among “Windows users”/“they”. This post was not intended to mean that Windows users are less knowledgeable/can’t use a command line, but to point out was is considered idiomatic/well accepted to install software on that platform. I apologize to those who may have taken this the wrong way.
Sure, but I’m optimizing for “smallest numbers of instructions I have to give to students”. Given that Windows is in the process of getting a standard cli package manager, it seems that we could get that done to two (actually three because they need to generate an SSH key too), the alternative is telling them to click and install a bunch of programs from a bunch of different sources which takes much longer and is easier to do wrong.
I don’t think regular users that installing stuff with installer are into development and especially into Scala, which require quite understating of cli tooling in first place.
In my opinion using coursier for management jvm and sbt is not really practical and redundant as there is already multiple native to platform solutions for managing packages like scoop/winget/choco/apt-get/brew/sdkman/asdf and many other well know projects. Also managing jvm by coursier wouldn’t friendly if you’re using other alternative manager, so I would avoid this part especially.
As professional developer I would rely on general purpose solutions instead of niche one unless it provides killer features. Also for practical purpose package manager require not only ability to install, but also manage updates, have updates database up-to date and manage global/local alternatives.
In summary I’m up-to native package management solution like
winget install java-11 vscode sbt ammonite
in one command, or at most two
winget install java-11 vscode coursier
cs setup sbt ammonite
It’s a bit of a hyperbole, yes. But as a daily Windows user and a Linux user, I can tell you that I have two very different mindsets when it comes to installing software. On Linux, I expect to be able to install them via my distribution’s package manager, or perhaps with a shell incantation. On Windows, I expect an executable that I can execute right from my browser. I am very suspicious of software that I need to install via a command line on Windows.
I know of plenty of Windows users who are much more well-versed in CLI usage than many Mac users I know.
Still, I wouldn’t say Mac users they don’t know how to use a complicated incantation on the command line, because that obviously doesn’t go for all of them, and it doesn’t serve any useful purpose other than alienating part of our userbase.
We could publish coursier to winget. It’s already on brew, for macOS. We would need to somehow clarify the ~story around those package managers.
Right now, downloading cs like
$ curl -Lo cs …
$ chmod +x cs
$ ./cs setup
actually installs cs itself too. And cs update can later update it. So that the cs file that was downloaded by curl can be removed right after having run ./cs setup.
If cs is installed in the PATH by brew or winget, we should ensure that we don’t install cs during cs setup. We don’t do that yet. And maybe we can print a message during cs update if we detect that a new coursier version is available.
I agree we should ensure double-clicking on the installer executable just works. But if winget were to gain momentum, like brew has on macOS, we could support it too.
Having spent ~15 years as a professional Windows dev, I’m with @sjrd here: while command-line installation isn’t unheard of, it’s weird. Frankly, it feels amateurish in the Windows environment: any serious tool has an installer. (Yes, I know that sounds weird from a *nix or Mac viewpoint – it’s a different world, and a different mindset.)
And while, yes, any programmer worth their salt is able to use a CLI, the installer version is friendlier to absolute beginners – which we have a lot of in the ScalaBridge world, and I think they are particularly likely to have Windows laptops.
So I think the Windows installer is likely a big win: it should smooth the path for a substantial number of people who aren’t Macbook-centric (the way that most of the Scala world seems to be, judging from looking around at conferences)…
On Linux, I expect a DEB or RPM file I can install via apt or dnf/yum respectively, and I am highly suspicious of software that doesn’t do that. I’m highly annoyed at IntelliJ IDEA for expecting me to download a ZIP file and unpack it myself. There are UI apps for package management on Linux, too, but usually I don’t bother.
On Windows, I expect an executable installer and would be highly suspicious of anything else.
IntelliJ IDEA is also available as a snap package. If you’re on Ubuntu 16.04 or later, you can install IntelliJ IDEA from the command line. sudo snap install intellij-idea-community --classic
or sudo snap install intellij-idea-ultimate --classic
or sudo snap install intellij-idea-educational --classic
Haven’t used that option, though.
I’m grateful for the ZIP option, as the laptop I’m using at work blocks (almost?) all installers.
I have all my personal hardware are running Windows, while my work station is Mac, and all my/company servers are running Linux, so I immediately started experimenting with package managers once they appeared on the scene, first it was choco, then scoop and now winget. And I would say it’s nothing strange, all windows packages are actually the same installers, but with orchestration scripts on top, as bonus they have uniform installation process and more granular dependency and permission control, so they suppose to be even safer than regular installers. In addition they have killer feature as alternatives control (as they usually installing in user space instead of system wide) which I was really missing.
By this off-topic I was trying to say, that trend on package managers on windows will be increasing and I think in couple of years it will be completely normal and old habits will change. Otherwise why cli tools are not shipped with DMG on mac? Additionally if you’re professional programmer you probably have several terminals with various environment - PS/CMD/WLS1/2.
I hope my argumentation in favor to package manager shipped option is understandable
