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

natemcmaster commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Please continue comment this issues if you think https://github.com/dotnet/cli/pull/10205 cannot solve the problem of your scenario and I will reopen it

cottsak commented 5 years ago

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

KathleenDollard commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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. :joy:

wli3 commented 5 years ago

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

(back to folding clothes)

Shoh commented 5 years ago

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.

wli3 commented 5 years ago

@Shoh i hope to understand your scenario better. You do not want to update to the latest version, but if according to your suggestion, with the new flag, the dotnet install will still install the latest version.

We added "--version" option to dotnet tool update (in 3.0.100 preview). If you want to pin to an older version, will always run "dotnet tool update mytool --version PINNED_VERSION" works?

wli3 commented 5 years ago

I created https://github.com/dotnet/cli/issues/11494 to discuss this specific option

Shoh commented 5 years ago

My use case (and I'm sure for many others) is for CI scripts. I should be able to put dotnet tool install (inserttoolhere) and not worry about it failing on subsequent builds. IMO, it doesn't feel right to use update when you're actually looking to just install a specific version.

Since the current behavior is to fail with exit code 1 when a tool is already installed, IMO, the safest solution is to add a flag to disable the "exit with error if tool is installed" behavior for users that opt to use the flag.

I thought either of the suggestions that were in dotnet/cli#11259 were fine (--slient|-s or --no-errors|-ne) but I'd be okay with something like --skip-installed.

Shoh commented 5 years ago

I will say that I agree with the others though, that the current behavior is not normal behavior and "gracefully failing" (i.e. exit with code 0 if already installed) should be the default behavior. If anything, the current behavior should be "opted" in, if a user wants it. i.e. something like dotnet tool install sometool --error-if-installed

I was just providing an option to satisfy the needs of those that want normal behavior without breaking or surprising any users that have gotten used to or have some reason to prefer the current behavior.

I am personally okay with including a flag to get the behavior that I want but I would prefer the current behavior to be "fixed" to something more normal. (If that was an option on the table) Again, ultimately, I'm okay with whatever is decided is best for the majority.

chrisgilbert commented 5 years ago

This broke our makefile, which tries to install 4 tools so we can use them to do various things - lambda, cake, and unit test coverage for an AWS lambda project we have.

If any one of the tools are installed, it will exit with a failure, and not install the rest (that's the normal behaviour of make).

That's not expected behaviour to me - I went searching for a way around it, and found this issue.

Since there's not a flag to change behaviour, to fix it we would either have to parse the exit text (maybe what I'll choose), or just ignore failures for any reason, and carry on with the rest of the installs (not ideal).

I can't presume exit code 1 is "success" though, because that's what it gives for DNS lookup failure, unable to connect to a nuget server, etc too.

Here's our example Makefile:

install-dependencies:
        dotnet tool install --global Amazon.Lambda.Tools --version 3.2.3
        dotnet tool install --global Cake.Tool --version 0.33.0
        dotnet tool install --global dotnet-reportgenerator-globaltool --version 4.2.1
        dotnet tool install --global altcover.global --version 5.3.675

dquist commented 5 years ago

Ran into this problem literally the first hour of trying to set up a CI pipeline for my first .net core 3 project. This behavior is so... disheartening and is bad DX.

The added upgrade option is nice I guess, but it still downloads the tool every time making it impossible to utilize pipeline caching.

All I want to do is install the tool if it doesn't exist without having to download any extra binaries. Why does this have to be so complicated?

rmsy commented 4 years ago

Is there any chance this is going to be re-visited? It is a little ridiculous that dotnet tool install returns 1 when the tool already exists. At the very least, would you consider adding a flag as proposed in #10242? This is inconsistent with the behavior of every other package manager out there, that I know of at least.

gravufo commented 4 years ago

How many people will have to complain here for Microsoft to stop burying its head in the ground and scream that everything is fine?

Edit: I saw that dotnet tool update was changed to have the kind of behavior we are expecting here. In my opinion, Microsoft still has it completely upside down. How does it make sense for a command called update to install if the tool doesn't exist whereas the install command fails if the tool already is installed??

kylecooleylba commented 4 years ago

Posting here because I agree with above comments should at least have a flag to return 0 if installed

zoechi commented 4 years ago

Makes it a pain in ansible

rmsy commented 4 years ago

@gravufo The dotnet tool update command "uninstalls and reinstalls a tool, effectively updating it." That is quite a joke and definitely not what an idempotent install command should do, so even that command can't serve as a proper substitute. The reality is that dotnet tool install should be a graceful no-op if the tool is already installed (as everyone here seems to agree, except for MSFT), and dotnet tool update should only update if there is a newer version determined to be available (but that's a different issue for a different thread).

eocern commented 4 years ago

Excuse me @wli3 did I miss a statement why "dotnet install" can not return 0 if tool is already installed ?

andersjonsson commented 3 years ago

I agree with everyone that this is a weird and unexpected behavior. Using dotnet update works and solves the problem but it's not an obvious thing. It sure isn't a "pit of success".

I just encountered this error on our CI-machine and had to google for a solution.

cliffchapmanrbx commented 3 years ago

Echoing previous discussion, I just now was trying to set up a CI for a dotnet tool and ran into this. Seems like the better UX would be to introduce what Invoke-WebRequest has with -SkipHttpErrorCheck, which doesn't throw an exception if you get a 4xx or 5xx response code.

dotnet tool install -g <tool> -SkipInstalledError would be a more acceptable workaround for me.

augustoproiete commented 3 years ago

@cliffchapmanrbx and others participating in this issue, you should upvote the issue https://github.com/dotnet/sdk/issues/10310 which is similar and is currently open.

Using .NET Tools in a CI pipeline is currently painful and requires a lot of scripting to handle errors, which should be handled by dotnet tool directly.

I suggested a couple of different approaches that could help. Adding a flag would improve the UX by a lot:

dotnet tool install toolname --ignore-if-installed

If changing the install command is breaking and not possible, creating a dedicated ensure command could work:

dotnet tool ensure --local toolname --version toolversion

Expectations:

If the command does not specify version, the latest version is installed. Exit code = 0
If the command specify version 2.0.0 and tool 2.0.0 is already installed, do nothing. Exit code = 0
If the command specify version 2.0.0 and tool 1.0.0 is already installed, upgrade to 2.0.0. Exit code = 0
If the command specify version 2.0.0 and tool 3.0.0 is already installed, downgrade to 2.0.0. Exit code = 0

More details:

bsolovij-ebsco commented 3 years ago

Any movement on this?

riverar commented 3 years ago

Chiming in here, update does not appear to be a valid workaround for preview versions, which require an explicit version be specified.

NaZaRKIN123 commented 2 years ago

A typical Microsoft way of doing things.

RDavis3000 commented 2 years ago

This is unintuitive This is also undocumented (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-tool-install) This is universally rejected by MS customers in this thread This is telling you that we don't need separate install/update commands This is telling you that in CI/CD world we want UPSERT everywhere and parameters for version targeting etc

cyril265 commented 2 years ago

How to annoy customers 101

Possible workaround without --update (reinstalling package every time). Remove --toolpath $NUGET_PACKAGES_DIRECTORY if you are installing it in the default directory.

(( $(dotnet tool list --tool-path $NUGET_PACKAGES_DIRECTORY | grep 'dotnet-reportgenerator-globaltool' | wc -l)==0 )) && \
dotnet tool install dotnet-reportgenerator-globaltool --tool-path $NUGET_PACKAGES_DIRECTORY

isidore commented 1 year ago

dotnet tool install -g <tool> | echo "already installed"

juescuder commented 1 year ago

@isidore solution works as a charm. Thanks.

HannahVernon commented 1 year ago

dotnet tool install -g <tool> | echo "already installed"

That's brilliant. Except I changed the echo output to "dotnet install is dumb"

dsplaisted commented 1 year ago

As an update, we're thinking of changing the install behavior so that it will not fail if the tool is already installed. This will mean that dotnet tool install will pretty much work the same way dotnet tool update already does. Because of that, over time we might deprecate dotnet tool update.

We would likely add options to allow the old behavior, for example something like --fail-if-already-installed and --update-only.

augustoproiete commented 1 year ago

That is good news @dsplaisted !

Expectations of future behavior that I believe most agree on:

dotnet tool install without a --version specified will try to update to the latest version when the tool is already installed, return 0 exit code if latest version already installed or if upgrade is successful, 1 otherwise
dotnet tool install with a --version specified will try to upgrade or downgrade to the specified version when the tool is already installed but with a different version than specified, return 0 exit code if specified version already installed or if upgrade or downgrade is successful, 1 otherwise

dsplaisted commented 1 year ago

@augustoproiete I'm not sure what the behavior should be if the new version is a downgrade. If a higher version is already installed maybe something depends on the higher version and would fail with the downgrade. Maybe we should error on downgrades by default and have an --allow-downgrade option which would allow it to succeed.

riverar commented 1 year ago

I do not agree with the proposed downgrade behavior. With --version present, a downgrade should be considered an error without a --force.

augustoproiete commented 1 year ago

@dsplaisted @riverar Following the principle of deterministic builds, if the --version is present it means my process expects that particular version every time it runs, consistently.

Thus, I'd argue that should be the other way around e.g. A --do-not-downgrade option, which would prevent a downgrade when a higher version is already installed.

edit: Also, the name of the option is --version... If option were called --minimum-version, then sure... I'd agree a downgrade would have to be --forced

LevYas commented 9 months ago

This is still a needed feature

baronfel commented 9 months ago

This should be released in 8.0.200 next month!

nagilson commented 8 months ago

Closing this as completed by @JL03-Yue, let us know if you have any feedback! 🥳

ay-azara commented 4 weeks ago

As an update, we're thinking of changing the install behavior so that it will not fail if the tool is already installed. This will mean that dotnet tool install will pretty much work the same way dotnet tool update already does. Because of that, over time we might deprecate dotnet tool update.

We would likely add options to allow the old behavior, for example something like --fail-if-already-installed and --update-only.

If I understand correctly, and based on what I'm seeing with on 8.0.402, the package is just reinstalled every time, even if the version is the same? It would've been nice to have it be idempotent like the issue author was requesting. Don't suppose this will change things now but current behavior feels wasteful of bandwidth and cpu when all we're doing is checking versions.

ronymeyer commented 4 weeks ago

As an update, we're thinking of changing the install behavior so that it will not fail if the tool is already installed. This will mean that dotnet tool install will pretty much work the same way dotnet tool update already does. Because of that, over time we might deprecate dotnet tool update. We would likely add options to allow the old behavior, for example something like --fail-if-already-installed and --update-only.

If I understand correctly, and based on what I'm seeing with on 8.0.402, the package is just reinstalled every time, even if the version is the same? It would've been nice to have it be idempotent like the issue author was requesting. Don't suppose this will change things now but current behavior feels wasteful of bandwidth and cpu when all we're doing is checking versions.

I agree with that. We have to use other workarounds as other parallel running processes which depend on dotnet tools fail when the update reinstalls the tools.

dotnet / sdk