Better discoverability of related packages

[khellang]

I first posted this over at #686, but I guess what I'm proposing here isn't what's "officially" called "optional dependencies".

Pulling in Microsoft.Framework.Configuration, as an example, doesn't provide much value by itself. In order to add configuration sources, you need at least one of the following packages:

• Microsoft.Framework.Configuration.CommandLine
• Microsoft.Framework.Configuration.EnvironmentVariables
• Microsoft.Framework.Configuration.Ini
• Microsoft.Framework.Configuration.Json
• Microsoft.Framework.Configuration.Xml

Currently, there's nothing telling the user that this is the case, and you have to either figure it out through trial and error, or consult documentation/code. In this case, it's pretty easy to see that the packages are closely related and they'd most likely end up in the same search result, but there is a huge discoverability problem for 3rd party NuGet packages today; If I had just pushed a package called AwesomeConfiguration.Toml, it'd be pretty hard to discover it (since very few have downloaded it yet) or know that it would add TOML support to your ASP.NET 5 apps. Is the solution to "mimic" the Microsoft packages and name it Microsoft.Framework.Configuration.Toml?

It would be super nice if NuGet had either

1. A way for Microsoft.Framework.Configuration to declare its own optional dependencies.
2. In reverse; packages could declare that they are an optional "dependency" (not really sure what it'd be called) for package X, i.e. Microsoft.Framework.Configuration.Ini is an optional dependency of Microsoft.Framework.Configuration. This would, IMO, be the best solution (but also the one with the biggest risk for spam?) as it fits most scenarios.
3. Both, the package itself declared "official" optional dependencies and external packages declared that they're "unofficial" optional dependencies.

The NuGet UI/command line could then simply list the optional dependencies and prompt the user if they wanted to install them together with the main package. Kinda like Yeoman does:

Does other package managers have something like this? What's the name for these "dependencies" or "related packages"? I've been looking around (and used quite a few), but I can't find anything like it.

I can think of lots and lots of use cases for this and I think it would open up some awesome discoverability scenarios and benefit the community as a whole.

[khellang]

It does sound a bit like @haacked's old proposal for "related dependencies", but not quite.

[haacked]

It does sound a bit like @haacked's old proposal for "related dependencies", but not quite.

It's very very similar to my proposal. All you have to do is add support for "NuGet" to the list of package sources for the original related dependencies and you would get this feature idea for free. 😄

But constraining it to just NuGet seems like a good stepping stone to "related dependencies". 👍

[praeclarum]

I would prefer a solution with a little more metadata so we can help guide consumers as to what they're choosing between. Perhaps a nice title is fine, or a description field.

Also it would be nice to support multiple dimensions of dependencies.

I'm thinking of the scenario:

1. Install NGraphics
2. Choose a platform (Mac, iOS, Android, UWP) that resides in another NuGet (note: this is not explicit given that some platforms have identical lib folders)
3. Choose rendering engines that reside in other NuGets

Basically I want two axes from which to choose my dependency lists. (Now I may be asking for too much since the combinations tend to grow.)

[loic-sharma]

Copying from https://twitter.com/khellang/status/1365366838004219909?s=20

These days I'm pretty happy, both as a producer and consumer of packages Ok handSmiling face with smiling eyes There are two things though; package disco. is a big one. Being able to link related packages together somehow, like peer dependencies, would be nice. And testing-driving packages in development.

Copying from https://twitter.com/sharmaloic/status/1365385639621849092?s=20

Interesting. I know that Composer (PHP package manager) lets you suggest packages that work well with your package: https://getcomposer.org/doc/04-schema.md#suggest

For example, when you install the Laravel framework you'll get suggestions on additional helpful packages to bootstrap your project. Great for discovery too.

This could also be used as a "soft deprecation". For example, when I install the still supported "OldPackage", it could suggest "NewPackage". We could also use this to improve search. If I search for "OldPackage", ideally "NewPackage" should show up too. Or if a popular package suggests "NewPackage", that probably means "NewPackage" is good and should be ranked higher.