Virtual Packages

[bricelam]

I want chocolatey-archive/chocolatey#7 to be implemented in NuGet.

Scenario 1

There are quite a few different versions of sqlite3.dll. For example, there is the official version shipped by the SQLite team. There is also SQL Cipher which adds encryption capabilities. The Microsoft.Data.Sqlite package could work with either of these packages.

It would be great if Microsoft.Data.Sqlite could depend on a virtual package named something like SQLite.Virtual. This dependency would need to be satisfied at install time, but it could be satisfied by either the SQLite or SQLCipher package.

Scenario 2

You could imagine a library that needs an IJsonSerializer, but doesn't care which one. They too could depend on a virtual package. The contract of the virtual package would be defined by the library. For example, they might use MEF to import the serializer.

[natemcmaster]

+1

Debian has a similar concept and it's very useful: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

[davidfowl]

Is it a dependency? How is it fulfilled if there are many of them? Which one wins?

[bricelam]

@davidfowl Yes, it would be a dependency. I like the idea of specifying a "default" implementation in the depending nuspec. A GUI could allow the user to select one.

Multiple implementations installed into the same project might need to be blocked, but it could also be left up to the contract to define. E.g. VS would error/warn if there are multiple files named sqlite3.dll going to the output directory; With MEF, you could just pick the "first" implementation, throw if there are multiple, or let the user configure which one gets used...

[FranklinYu]

It has been more than two years. Is there any update?

[davidfowl]

Nope

[FranklinYu]

Then is this feature ever considered? Would at least Pull Request be reviewed and merged? (Only after that we can discuss about possible implementation details.)

[FranklinYu]

If we name the virtual package with SQLite.Virtual as proposed by @bricelam, we would need both Microsoft.Data.Sqlite and SQLite.Virtual maintained separately (two .nuspec files) because we need some way to specify that default implementation for SQLite.Virtual is Microsoft.Data.Sqlite. I propose that the virtual package called Microsoft.Data.Sqlite directly, so it is immediately clear which one is the default implementation without maintaining another .nuspec file. Currently we specify dependency with

<dependency id="Microsoft.Data.Sqlite" version="*"/>

According to specification, version is required. For virtual dependency we can have

<dependency id="Microsoft.Data.Sqlite"/>

(Virtual packages in Debian don't have version either.)

Similar ideas for RPM.