Putting the installation method of scala-cli in an environment variable or a metadata file

[zmerr]

Related to issue #543 currently, if a user forgets the previous method they used for installing scala-cli on their system, they might use another one for reinstalling. This creates a duplicate in PATH; therefore, even when a newer version is installed later, through a second method, this would be the old version that might show up first on PATH and get executed.

How it should behave:

The user types scala-cli —version or scala-cli about or scala-cli update.
Then the user receives information about the method with which they have installed scala-cli, for example Homebrew; and instructions get shown to them about how they should update scala-cli using this installation method, such as Homebrew.

How it can get Implemented :

We create a hidden command for scala-cli such as installMethod which then gets run by the installation tool, post installation. Upon receiving a command like scala-cli installMethod brew, Scala CLI creates an environment variable called $SCALA_CLI_INSTALLATION_METHOD and assigns the value brew to it.

This way, each time the about, version, or update commands are called; scala-cli can just read the value of this environment variable for knowing how it is installed, or even update itself through the same method.

Alternatively, the installation method can be written by the installation method to a metadata file put in the same directory as the executable file of scala-cli. Then scala-cli can read the contents of this file for responding to the above mentioned commands. The downside of this method is that the metadata file would get lost upon an installation directory change.

[zmerr]

using Java Properties is another alternative for creating the metadata file:
https://docs.oracle.com/javase/tutorial/essential/environment/properties.html

Determining the location of this file remains an issue.

[alexarchambault]

About this, I think a hackish way of doing could consist in appending a zip file at the end of the binaries right before putting them in packages. That zip file could contain an entry, like META-INF/scala-cli/source.json say, with a few metadata, like the package type, the typical command to update it, etc. Then the update command could try to open the binary path as a zip file, and check for that entry.

[Gedochao]

Given the number of installation methods and platforms we support, I do not believe it likely for us to have the resources necessary to hack this in a stable manner.
If anyone has a sane idea on how to implement this, then by all means, feel free to reopen.
Otherwise, closing for now, we won't fix this.