Add doctor command to diagnose common problems and print information for further debug

[zmerr]

Having more than an instance of scala-cli on PATH creates problems with updates, since an old version might appear sooner on PATH and get executed instead of the newer version!

How should it work:

The user runs scala-cli doctor

Then, if there are any duplicates on PATH it gets reported to the user!

One implementation strategy is

• first seeing if type -ap scala-cli shows duplicates;
• then if so, we run ls -l on the result to make sure they are not all symlinks to the same location.
• Then if they were not symlinks, we cat the contents of them to see if they run the same script. (this is tricky)
• Now if they weren’t scripts executing the same thing, we produce a PATH duplicates error

Alternatively, this information can be provided by running the update, about, or version commands.

The team decided that the PATH duplicate part of issue #543 should be dealt with as an independent separate issue. It is also related to issue #670

[zmerr]

related to PR #663

[SethTisue]

Let's call it doctor, in imitation of Homebrew (and also Metals, according to @romanowski).

[mtk]

why isn't the delivery of scala-cli managed by coursier?

[romanowski]

why isn't the delivery of scala-cli managed by coursier?

It can be. Scala CLI is designed to be installed using a method native to most users (brew, apt-get etc.) to make onboarding process as easy as possible and beginner-friendly. Using coursier is one of the options however it requires to have installed coursier.

[romanowski]

We have discussed a bit about the scope of doctor command and we decided that it should provide the following information:

• current version / latest version + potentially information that scala-cli should be updated (and that should take SNAPSHOT version into account and mention that one is ahead of stable version)
• the state of bloop (running/not running + version and JVM used)
• if there are duplicated scala-cli on classpath
• whether all native dependencies for native / js are installed
• information about location of binary / main class that is being used
• information if scala-cli can access Maven central / scala-cli github with some tips and diagnostics about proxies (@alexarchambault could you provide more details on what can be printed?)
• information if scala-cli is used as a native application or is using JVM

[mtk]

re: coursier - i get your point. strategically, i think it should be delivered by coursier, though. if you're going to pay the climbing-the-learning-curve price for only one tool (e.g. as a student in a class), installing coursier manually gets you more for your money. chris kipp asked me to open a coursier issue requesting that scala-cli move out from under "install --contrib" to just "install". haven't done it yet but i will.

re: doctor - that's a great list of things to-do. speaking only for myself, that won't fit into two hours. for some reason i didn't see your post until today. however, i'd be happy to work on this well after the spree ends.

[mtk]

krzysztof, what did you mean by this?

information about location of binary / main class that is being used

[lwronski]

krzysztof, what did you mean by this?

information about location of binary / main class that is being used

We want to detect the location binary/jar launcher of Scala CLI.

Krzysztof wrote main class but I think, he was thinking about the location of launcher jar. It would be nice to detect if someone uses scala-cli from cs, something like this:

cs launch -r sonatype:snapshots org.virtuslab.scala-cli:cli_2.13:0.1.3-16-g07b08ea7-SNAPSHOT -M scala.cli.ScalaCli -- "$@"

or, if someone uses jar launcher Scala CLI from local build. It may be helpful to analyze some bugs.

[mtk]

ah, thank you Łukasz!

[anatoliykmetyuk]

This issue was picked for the Issue Spree 15 of May 3rd which takes place a week from now. @mtk and @anatoliykmetyuk will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[ValeriePe]

This issue was picked for the Issue Spree number 16 of May 24th which takes place in a week from now. @SethTisue @mtk will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[mtk]

@asjad02 asjad may sign up for this too again. right now i'm hobbled by the fact that './mill mill.scalalib.GenIdea/idea' and '.mill mill.contrib.Bloop/install' both fail reliably. i've created both a scala-cli issue and a mill issue about it (seems like a mill bug to me though).

[mtk]

the scala-cli build.sc bug and the minor (bad error message) mill bug have both been fixed, btw.

[ValeriePe]

This issue was picked for the Issue Spree number 17 of June 14th which takes place in a week from now. @anatoliykmetyuk @mtk will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[mtk]

actually, i was thinking about this. i think toli & i should try to meet w/lukasz and/or w/seth to talk about the web access checks. will try to schedule it.

[ValeriePe]

This issue was picked for the Issue Spree 18 of July 5th which takes place in a week from now. @mtk @deniszo will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[Gedochao]

Noting here, so we don't forget about it. Even though #818 was merged, it seems there's still relevant effort to be done. relevant comment: https://github.com/VirtusLab/scala-cli/pull/818#issuecomment-1084793516

[mtk]

was hoping to work on it during the next spree.

[ValeriePe]

This issue was picked for the Issue Spree n° 19 of August 16th which takes place in a week from now. @anatoliykmetyuk @mtk @markehammons will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.