Open keynmol opened 1 year ago
Related to this issue: https://users.scala-lang.org/t/streamlining-the-scala-installation-procedure/9313
I'm in general agreement with Anton here about the advisability of coursier
continuing to be its own command-line thing and its own package manager. I posted similar thoughts at https://contributors.scala-lang.org/t/sip-46-scala-cli-as-default-scala-command/5996/64
I think we could include some of the commands such as launch
, but I would not opt to do add everything that coursier does as I am not sure if we could provide a sensible level of support here.
I can just say that installing more things on some corporate networks is next to impossible so anything to simplify and have official "signed" launchers/installers is highly desired.
I would also love to see one feature to setup the JDK using Scala-CLI alone. May be as a power flag or a sub-command or any other way. Right now, I promote cs
to a lot of my colleagues and friends to manage JDKs. I also tries to promote scala-cli. So thought, it might make it easier if we can do the JDK explicit setup using Scala-CLI itself instead of separate cs install.
Scala CLI already embeds a non-trivial portion of Coursier for its dependency resolution needs.
I propose exposing
scala coursier
as a separate command with subcommands such as (but not limited to)launch
resolve
fetch
bootstrap
to provide immediate access to the full ecosystem of packages, coursier channels, etc.
Currently coursier is in a weird place – it's the de facto dependency resolution mechanism for both SBT and Mill, it is the official way of installing Scala, it is used to resolve and bootstrap CLIs, it has incredibly helpful poweruser functions to fetch classpaths and resolve dependency trees.
And yet:
With Scala CLI being the official launcher (and hopefully at some point being simply a
apt install scala
away...), I believe requiring a separate installation of coursier to get access to same functionality is unnecessary.Workaround for the impatient: