Design and implement a notion of package type to support tool packages

[joelverhagen]

The goal is have a way to mark a package as a tool so that it can be properly installed to the "tools" node in the project.json (instead of under "dependencies").

[joelverhagen]

Working document:
https://github.com/NuGet/Home/wiki/Package-Type

[davidebbo]

Context: I chatted with @yishaigalatzer about using PackageType for a different type of packages (not related to CLI tools).

My main feedback on the working document is that it is too much about addressing .NET CLI Tools. The proposal may be more general, but the document does not convey that well. It would be nice to rephrase it in a more general way, with CLI tools being used as just an example, rather than it being the goal of the feature.

[joelverhagen]

@davidebbo, thanks for the feedback. Totally agreed. I was shooting for a specific, well-understood scenario to inform package type. Package type could potentially be a concept that blows up with too many requirements (considering that NuGet is already used for all sorts of, well, "versioned blob" delivery, i.e. Chocolatey, Octopus deployments, etc).

Could you provide some more details about your specific scenario?

Depending on your scenario, one detail you may find concerning is under the Installation heading:

If a package has no explicit package type, the package is assumed to be a dependency. If a package has an unrecognized (not DotnetCliTool or Dependency) type or more than one type, the installation fails.

This is talking about the installation procedure invoked in the Visual Studio UI or the Install-Package PowerShell command.

[joelverhagen]

@davidebbo, @harikm86, I've improve the documentation to walk through a simple custom package type example:
https://github.com/NuGet/Home/wiki/Package-Type#other-package-types

[davidebbo]

I can give two specific scenarios:

1. Azure Web App site extensions. We currently have our own gallery (http://www.siteextensions.net/), but want to get out of the gallery hosting business. Having our packages on NuGet.org with the right package type (e.g. "AzureSiteExtension") would work.
2. Our new Azure Functions. We're working on an upcoming extensibility model that will be NuGet based. Again here, we don't want to host our own gallery.

In both scenarios:

• We don't need any extra metadata fields in the nuspec beyond the default ones
• We will have our own installation experience, so no concern about VS not supporting them. In fact, we'd want VS to ignore them!

Does that look like it will be covered by the current design?

[yishaigalatzer]

yes