Sdk: Tool management experience - update, list, uninstall

[dasMulli]

Since dotnet install tool -g allows installing commands, there should be additional commands to manage the installed tools.

This includes:

• Listing installed tool packages and command names they provide.
• Updating tools (one specific or all)
• Listing outdated tools (could as well be update with a "pretend"/"whatif" flag or included in a listing command)
• Uninstalling tools

does dotnet install tool -g record any metadata at the moment? If any of the experiences above will be enabled in future updates/previews, metadata should already have been recorded for versions that didn't provide these management experiences.

cc @wli3 @livarcocc @KathleenDollard

[wli3]

We have _list_ and _uninstall_ on the map. We have some design on update scenario but has not been concrete yet.

dotnet install tool -g does not record any extra metadata today, if you don't count asset.json. We try to use folder structure to do the book keeping.

And @KathleenDollard for schedule questions.

Also, could we treat this issue as a question? And close it when it is answered? It is hard for us to track a list for features using one issue.

[dasMulli]

I did intend this to be more of a discussion than actual work items.

[aL3891]

It would be kind of nice to have a standardized "help" command, but I guess that can also be done by the tool itself. If there were a help command, the tool could just specify a text/json file with all its switches and help text

eg

dotnet help tool

[KathleenDollard]

I'm really glad that our plans are in line with the requests.

I think we are on track for list and uninstall after Preview 1.

We decided that "update" was the start of some larger conversations - and if we aren't ready to tell you what is out of date, install -g --force seemed enough. The larger conversation includes deciding if/how we want more control managing versions. That conversation will happen after we make the basic feature available and can focus on how to make the right experience.

What we have in mind for "help" and many related problems, including parsing and tab completion, is to provide a consistent CLI parser. We're very early in that conversation and whether it's the right solution to evolve and make more easily available the parser used in the CLI. Command line parsing is an onion - with both the surprising number of complexities and the tears. Having an option part of the SDK seems desirable.

I'm want to hear how you want the tools experience to evolve from a producer's/tool management perspective.

---

From: Allan Lindqvist [e-mail]
Sent: Monday, January 29, 2018 1:05 AM
To: dotnet/cli
Cc: Kathleen Dollard; Mention
Subject: Re: [dotnet/cli] Tool management experience - update, list, uninstall (#8492)

It would be kind of nice to have a standardized "help" command, but I guess that can also be done by the tool itself. If there were a help command, the tool could just specify a text/json file with all its switches and help text

eg

dotnet help tool

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcli%2Fissues%2F8492%23issuecomment-361181206&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7C851528e497ed43fbcb1f08d566f7645c%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528135081774136&sdata=xS%2FOexn8GM8Ol6uU%2FtdZkOx4GTq1Vl7Eox%2FJdGaYcns%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFktXgSF4Y0KJHKzRZJ4gEE0T7gL71tgks5tPYnBgaJpZM4Rvu47&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7C851528e497ed43fbcb1f08d566f7645c%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528135081774136&sdata=JQKXuGpYPil3FwxgptiP6imI8Gnwq2s4B7Rvt0wPAgM%3D&reserved=0.

[dasMulli]

I concur with list and uninstall being the next important verbs after installing tools work.

I'm a bit worried about the install tool combination - since the "obvious" list command would be dotnet list tool -g, I think it clashes a bit with the dotnet add and dotnet remove commands, since they both intersect at dotnet list.

So I have list to work with tools and references, but these classes of "things" have different pairs to manage install/uninstall(?) for tools and add/remove for references.

If tools should also be managed for project-local CLI tools, this would probably make sense to be done with dotnet add/dotnet remove as well (there were talks on nuget/home about possibly allowing nuget's install logic to make the determination based on the package's packageType metadata).

Then there is the sln family of verbs - dotnet sln add / dotnet sln remove.

To me, it feels like tool management would fit more naturally with the sln pattern to distinguish itself a bit from the existing commands to modify projects and solutions.

This would allow the commands to form clusters based on the concerns they deal with:

Tools: dotnet tools install / dotnet tools list / dotnet tools uninstall…
Solutions: dotnet sln add / dotnet sln remove
Projects: dotnet add (package|reference) / dotnet remove (package|reference) / dotnet list reference

With projects not having a "prefix" because they are used most frequently.

[dasMulli]

Another benefit of putting it under a dotnet tool verb would be better discoverability.

If I know I want to do something with my tools, I would type dotnet tool -h or just dotnet tool and try tab completion to get the list of commands that have to do with tools.

I do that all the time now with dotnet ef - they don't have dotnet ef update database but dotnet ef database update, which is good because I can just type dotnet ef database to get a list of possible things I can do on databases.

[livarcocc]

Closing this as we have now moved to dotnet tool and it has install, uninstall, update and list.