sdk: When installing a .NET local tool, create the tool manifest if one does not exist
When a user tries to install a .NET tool as a local tool on a folder that does not contain the manifest, we get an error Cannot find a manifest file.
> dotnet tool install --local Cake.Tool --version 0.38.4
Cannot find a manifest file.
For a list of locations searched, specify the "-d" option before the tool name.
If you intended to install a global tool, add `--global` to the command.
If you would like to create a manifest, use `dotnet new tool-manifest`, usually in the repo root directory.
However, if the user tries to update an existing local tool, dotnet tool is able to update the existing manifest:
dotnet new tool-manifest
dotnet tool install --local Cake.Tool --version 0.38.4
dotnet tool update --local Cake.Tool
Tool 'cake.tool' was successfully updated from version '0.38.4' to version '0.38.5' (manifest file /Users/augustoproiete/.config/dotnet-tools.json).
TL;DR; It would be great if dotnet tool install automatically created the tool manifest, if one does not exist when installing a local tool, instead of failing with an error.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 7
- Comments: 16 (7 by maintainers)
Finding an analog, NPM does this by default as well with package.json and puts it in the right place. Users who do
npm install momentfor example, get a non-global package and a package.json dropped in the right place. We should have the similar and easy experience reducing the ceremony for such things.Add a
--forceor--trust-meparameter so users can convincedotnet toolthat they know what they are doing? 😄Sorry, I just saw this ping. I worry that an optional flag (especially a long one!) will get very little use, especially with the very low rates of tab-completion registration and usage. What if we
--manifest-fileoption to specify the manifest to add to (and side-step the entire walking algorithm if present)--create-manifest-if-needed falsethat forbids walking (and therefore requires either explicit--manifest-fileusage or the.config/dotnet-tools.jsonto be present in the current directoryThat would make the simple usage do what the user intended, while also giving automation tools to more firmly specify the inputs when required.
@wli3 The end goal is to be able to run a command (or set of commands) that ensures that a particular dotnet tool, of a particular version, is installed.
Use-case: Write a set of instructions on how to add a dotnet tool, that someone can copy/paste and run, and it always works.
Let’s examine the following example:
At the moment, it’s impossible to guarantee that the instructions above will work for everyone, because:
dotnet new tool-manifestthrows an error if a manifest already exists (exit code != 0)dotnet new tool-manifest --forcereplaces the existing manifest - which is not the goal when you just want to add a new tool to the existing manifestdotnet tool install toolnamefails if the manifest does not exist (exit code != 0)As you can see, it’s impossible to send someone a set of instructions that will always work when they run.
Would it be possible to have along the lines of the following:
So that both commands above do not throw an error, and return exit code = 0.
I also suggested an alternative approach on https://github.com/dotnet/sdk/issues/10310#issuecomment-757602576 which aims to achieve the same goal: Ensure that a dotnet tool is installed, without throwing errors.
The above would mean that the manifest is created automatically, so that everything can be done with one command.
Expectations:
/cc @KathleenDollard
The current behavior – asking the user to run
dotnet new tool-manifestis about the same level of work comparing with asking the user to add a parameter todotnet tool ...command. I think it is fine adding another option. But I don’t think it should be the default