Document the acquisition experience of tarballs/zip files

[Sridhar-MS]

Should we be using something like https://github.com/dotnet/cli/blob/master/scripts/install.sh?

[brthor]

Currently we use this install script in our own build to install stage 0.

#4489 is tracking the inconsistencies between that script and the deb/pkg installations.

Are there changes we need to make besides ironing out those inconsistencies?

@blackdwarf @piotrpMSFT

[blackdwarf]

@brthor there are two things why I wanted this issue to exist:

1. In order to make a call on whether manual installing is using a script or using very manual works (i.e. curl the tarball, untar it, copy etc.)
2. If we make a call on using a script (a-la install.sh/install.ps1) to track the work needed to make sure that the script is ready for consumption.

For instance, if we are using the script, then I see no reason that the environment variables that currently exist should be there, you should also be able to specify the target directory where the binaries should be unzipped etc. If we go the script way, we should reuse as much as possible from install.sh/install.sp1 but decouple it from our build for external users (should make it simpler).

Thoughts?

/cc @piotrpMSFT

[blackdwarf]

After some consideration, I think we should have two ways of getting the "local install" up and running:

1. 100% manual way
2. Install scripts (install.sh for *nix and install.ps1 for Windows)

The first is easy enough to reason about. The users download the archives (zip/tarball) and then unzip them to a given location. They need to set all of the environment variables manually and so forth. This is a way to install that is provided by the virtue of archives being on a publicly accessible feed. :)

The second way would rely on similar logic that currently exists in the install scripts for our own build, but would be decoupled and allow for at least two parameters at invocation:

1. The target directory where the tools should live
2. The version/channel so you can download different things and reason about what you are downloading. You may not want to have the latest all the time.

Updating bits through this mechanism would be to just re-invoke the script(s) with exactly the same parameters for install location and different parameters for version, and that would mean that your install location is overwritten with new bits.

Both of these would require the user to pre-install the prerequisites for the CLI to run based on documentation that we need to add.

Thoughts?

/cc @glennc

[glennc]

Given that this is for end users we should check for pre-reqs as well if we can, and at least warn if they aren't there.

I see no reason at the moment why this script couldn't be used in the build as well though, no need to maintain two.

[blackdwarf]

@glennc sure, whether they are separate or same is really just a decision of the implementer. ;) We can check for pre-reqs, that's a good idea.

[Sridhar-MS]

There are already some checks for pre-reqs in install.sh.

[blackdwarf]

@piotrpMSFT @glennc @Sridhar-MS @brthor are we fine with this plan moving forward? Also, @glennc are you on board to change the installer scripts?

[blackdwarf]

OK, so @krwq is changing the installer scripts and dotnet/cli#1482 is tracking the spec. I will close this issue since it is out of date and this point.