dotnet tool install should return exit code 0 if tool is already installed

[natemcmaster]

I'm trying to write a script that will install global tools if necessary. I would like to just run "dotnet tool install", but this returns exit code 0 if the tool is already present, so I have to first execute dotnet tool list and grep the output.

Expected behavior

Calling dotnet tool install should no-op AND exit code 0 if the tool is already installed

Actual behavior

Running dotnet tool install twice fails scripts because the second time it runs it will exit code 0

PS> & dotnet tool install --tool-path "$(pwd)/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json
You can invoke the tool using the following command: sleet
Tool 'sleet' (version '2.3.25') was successfully installed.
PS> $lastexitcode
0
PS>  & dotnet tool install --tool-path "$(pwd)/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json
Tool 'sleet' is already installed.
PS>  $lastexitcode
1

The result of this is that I have write more complicate code like this:

if (& $dotnet tool list --tool-path "$PSScriptRoot/.tools" | Select-String "sleet") {
    Write-Host -f Yellow 'Skipping install of sleet. It''s already installed'
}
else {
    Invoke-Block { & $dotnet tool install --tool-path "$PSScriptRoot/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json }
}

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\dev\aspnet\Universe20\.dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  2.1.300 [C:\dev\aspnet\Universe20\.dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.NETCore.App]

[wli3]

Another side of the coin will be "I don't know if it will trigger asset download if I run this command". I slightly prefer current approach. But note, both approach will cause another side unhappy.

[natemcmaster]

Another side of the coin will be "I don't know if it will trigger asset download if I run this command"

Can you explain more what you mean? I'm not sure I understand the concern. It seems clear to me that when calling "dotnet tool install" I may download some assets.

[wli3]

related issue https://github.com/dotnet/cli/issues/9064

If exists return 0 has extra magic. The installation is triggered or not depends on the existing disk state. The current approach i think is more strict which is better for script since it is less likely to swallow error in script.

Also, "dotnet tool install" is not idempotent at all. It will download a different version if there is new version in the feed. In this case, what "dotnet tool" install should do when this happens and what the user will expect? And the expectation will also be different for scripting and user typing. The current strict approach will move this question to the user which I think is better than mismatch expectation.

[natemcmaster]

This is overly strict and IMO a bad default. The error code currently issued (exit code 1) is the same error code issued for legitimate errors, so I can't just swallowed the error and move on.

You've brought up a good point though -- what to do about versions. IMO it would be good to look at what other tools do, e.g.

brew install
apt-get install
npm install

From my experience with these, running install (without a version) will return exit code 0 and will not attempt to upgrade if the tool is already installed. Running install with a version will attempt to run and upgrade (or downgrade) to bring the installed tool into alignment with the value of --version

cc @KathleenDollard @richlander

[tmds]

npm install returns 1 when it can't change to the specified version.
npm install returns 0 when the version is already installed.

npm install without a version specified will update to the latest version when the package is already installed.

This matches my expectations as a user.

[KathleenDollard]

Will and I talked about this.

We do not currently determine what the version of a tool is. Install fails if it is found, update uninstalls and reinstalls it regardless. And, we're concerned about users being able to differentiate between "we didn't do anything" and "we think you are in a broken state".

All of this relates to a decision we're working on regarding whether we use a manifest for repo tools (expected) and whether we retrofit that approach to global tool or have two different internal approaches. If we change global tools to maintain manifest, it will be easier for users to understand what they have requested, for us to understand the version that is present, etc.

So, this is on hold for a bit.

[ErikSchierboom]

npm install returns 1 when it can't change to the specified version.
npm install returns 0 when the version is already installed.

npm install without a version specified will update to the latest version when the package is already installed.

This matches my expectations as a user.

I agree!

[wli3]

Please continue comment this issues if you think dotnet/cli#10205 cannot solve the problem of your scenario and I will reopen it

[cottsak]

It's so frustrating not to get the common convention of a 0 exit when the tool installs or is already present.

[KathleenDollard]

@cottsak Is there a reason using dotnet update instead of dotnet install is a bad choice when you want to either install or update depending on whether the tool is on the box?

[cottsak]

@KathleenDollard It's not a "bad" choice. But IMO, it's less than ideal. When scripting something it would be great to simply use dotnet install as an idempotent command meaning that it will implicitly "install" if not present, or return 0 if it's already installed. It just makes life easier, and seems to be an established convention.

[sandcastle]

I honestly think if a survey was run (focused on ux), it would clearly show that the current behaviour is not preferred. It's inconsistent with so many other experiences like the ones @natemcmaster mentioned above.

No joy is being sparked with the current behaviour. 😂

[wli3]

Replied here https://github.com/dotnet/cli/issues/11259#issuecomment-487447234

(back to folding clothes)

[Shoh]

I don't understand why a flag can't be added, like it was suggested in dotnet/cli#11259, and just be done with it? It's not removing or changing any default behavior (so no users will be surprised) and it will satisfy the needs of all those that want the option to not throw an error when installing a tool that has already been installed. Using dotnet update is NOT a proper solution for it. What if I don't want to update a tool every time a new version is released? Because it's usually not a good idea to update right away for most things (for obvious reasons).

Please just add the flag and be done with it so we can all continue with our work.