Rename And Re-Reference The Coursier CLI Usages

[maxstreese]

Proposed Change

Rename and re-reference the Cousier CLI from coursier to cs.

Motivation

For some time now the Coursier CLI is named cs instead of coursier. However in both the Bloop documentation as well as the code it is still named/referenced as coursier. I think this should be adjusted for two reasons:

1. Documentation Alignment

The change should be made to make the documentation of Bloop and Coursier more aligned and not cause confusion. This point is purely about changes to the Bloop documentation (replacing coursier with cs).

2. Make Bloop Functionalities Work By Default

The change should be made to make at least one functionality of Bloop actually work with recent default installations of Coursier. The functionality I am referring to here is bloop console <some-project>. The part of the source-code of Bloop that makes this happen is still assuming to find a CLI named coursier and not cs somewhere on the path which will not find anything if Coursier is installed in the recommended and documentation way.

Possible Solutions

Below I want to provide some points on possible changes that could be performed. These points are not all exclusive but can be combined. I would recommend doing point 2 combined with either one of 3 to 5.

1. Don't do anything because Scala 3 will do things differently anyway or Bloop functionality will be integrated into SBT or whatever (I am not aware of any of this so if someone knows more than me please let me know)
2. Rename all mentions of coursier to cs in the documentation
3. Re-Reference coursier to cs in the Bloop source for bloop console (and any other references I did not find)
4. Do what is written in point 3 but do it such that both are still possible and one is default and one the fallback
5. Re-Write the functionality of bloop console such that it makes use of the Coursier library instead of relying on an external CLI (I do not know if this is possible or desirable though)

Final Words

If some maintainer could give some feedback on this I would be happy to take a stab at it. I just need to know which direction it should be. Thanks!

[tgodzik]

Thanks for reporting!

Don't do anything because Scala 3 will do things differently anyway or Bloop functionality will be integrated into SBT or whatever (I am not aware of any of this so if someone knows more than me please let me know)

Scala 3 should work almost exactly the same while all the tooling is in place.

Rename all mentions of coursier to cs in the documentation

We could do that, especially that most people will be using cs now, though coursier is still used for the jar based launcher, so not 100% sure about it.

I would recommend doing point 2 combined with either one of 3 to 5.

I think if possible it would best to do 5, we already do a similar thing in Metals:

https://github.com/scalameta/metals/blob/65c1ec565efbe30ac6016a096df4175714301a3d/metals/src/main/scala/scala/meta/internal/builds/ShellRunner.scala

This would mean we would essentially only run a java process, which we already have access to.

Otherwise, I would opt for 4.

Let me know if you need any help with it!

[maxstreese]

Hi @tgodzik,

Apologies for getting back so late. I did take a look at point (5) and it's easy enough in a dummy application:

import coursier._

val ammDep = dep"com.lihaoyi:ammonite_2.13.5:2.3.8-58-aa8b2ab1"

val cp = Fetch().addDependencies(ammDep).run().mkString(":")

val pb = new ProcessBuilder(
  "java",
  "-classpath",
  cp,
  "ammonite.Main"
)

pb.inheritIO()

val p = pb.start()
p.waitFor()

The above assumes a recent version of the Coursier API but is otherwise dependency free. Packaging into a static binary via GraalVMNativeImagePlugin works on my machine using GraalVM CE 21.0.0.2 with OpenJDK 11.0.10. It's obviously not final as things like the Scala version, Windows differences in the classpath and passing along flags to Ammonite are not covered. But those I should be able to include easily looking at the current Bloop sources.

The questions I have are rather these:

1. Bloop uses Nailgun. I can see that the current code for the console in the frontend simply writes the command to be invoked to some out-file which is later somehow picked up by bloopgun which I assume to be the long running server part of Bloop. Can I replace this part in the front-end and tell it to invoke Ammonite like above directly? (As a side question: Why use Nailgun at all and not have all of Bloop be some static binary packaged via native image? Is there some reflection stuff that prevents this? Is this not desirable for some reason?)
2. The console function returns a Task[State]. My guess is it's fine for me to put something like the code above inside a try-block (equivalent to how the out-file is currently written) and then just call Task.now(state.withDebug("<meaningful-message>")(DebugFilter.All))?

[tgodzik]

1. Bloop uses Nailgun. I can see that the current code for the console in the frontend simply writes the command to be invoked to some out-file which is later somehow picked up by bloopgun which I assume to be the long running server part of Bloop. Can I replace this part in the front-end and tell it to invoke Ammonite like above directly? (As a side question: Why use Nailgun at all and not have all of Bloop be some static binary packaged via native image? Is there some reflection stuff that prevents this? Is this not desirable for some reason?)

There is more info about snailgun (Scala nailgun client) here: https://github.com/jvican/snailgun
You can read the motivation behind it there.

I think the biggest issue here is that the Bloop server actually knows things about the codebase and you have a separate native image client app, which is Bloopgun. The way it currently works is that we send the console command via Bloopgun to Bloop server, which writes the command to the file, which is later invoked by the Bloopgun client.

What we can do is maybe only write out the classpath to the file (instead of the full command) that we can later use to invoke the actual ammonite command inside Bloopgun.

I touched the code around this here: #1451

2. The console function returns a Task[State]. My guess is it's fine for me to put something like the code above inside a try-block (equivalent to how the out-file is currently written) and then just call Task.now(state.withDebug("<meaningful-message>")(DebugFilter.All))?

Not sure if that will work. Frontend is not the thing that is actually being invoked.