Optional Dependency support

[csharpfritz]

With transitive dependencies, it would be nice to have dependencies be optional. Consider: https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

[yishaigalatzer]

CC @davidfowl @lodejard

I don't think this is high priority (possibly not even needed). Moving to backlog for now, if you feel differently please let me know

[khellang]

I'm not sure it's quite the same thing, but here it goes anyway;

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 these 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 made an awesome package called AwesomeConfiguration.Toml, it'd be pretty hard to discover it and 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.

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.

Does this make sense?

[khellang]

And speaking of discoverability, are there plans to introduce search by dependencies? That would also make it easier to discover packages, i.e. search for packages that depends on Microsoft.Framework.Configuration.

[patriksvensson]

👍 for @khellang's suggestion.

[M-Zuber]

I second the notion put forward by @khellang

[yishaigalatzer]

@khellang his does seem unrelated, but also very interesting. Not sure a package could/would declare optional dependencies for this purpose this seems opposite. It still seems like a valuable discovery mechanism. Could you please file a separate issue with this suggestion? Also an issue for search separately.

On the server side we are currently focused on scalability and stability when this push is over we plan to work on search improvements again, so this is a good time to hash this idea.

[hyrmedia]

👍

[jorgebay]

Trying to bring back the discussion from OP @csharpfritz, it would be nice to have a way to declare optional dependencies, limiting optional dependency version ranges. There are many use cases that justify having optional dependencies.

Its present in other build and package managers like maven and npm. Would it be possible to bump the priority on this one?

[jorgebay]

Any info on why this was closed @rohit21agrawal ?

[rohit21agrawal]

@jorgebay Couple of reasons - we are closing bugs that have not been active for over a year, and two, this doesn’t fit in with the plans we have for NuGet in the near future.

You can open a new issue if you have a strong case for this feature and we would consider it.

[SamB]

Debian calls those Suggests (or maybe Recommends?) and Enhances, FWIW: https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

[Mart-Bogdan]

Oh. It's closed, and seems that @jorgebay haven't created follow up issue.

I have a use case.

Library that define new data type. For eaxample date/time or utf8 strings https://github.com/U8String/U8String

Might define serializers and deserializers for example for Newtonsoft Json.
For this it needs to created classes that implement serializer and annotate main class with attributes.

Otherwise end users would need to load separate library and register serializers/deserializers manually.

IDK if dotnet allows assembly to load if it don't have all dependencies resolved.

It works in Java world. It allows to have so called provided dependencies. You won't be able to use classes that inherit from unknown type, and if you try to fetch annotations that aren't loaded they would be ignored.

Is this even possible in dotnet?