Virtual packages

[mcandre]

Could Chocolatey add aliases, so that packages like gnuwin32-grep.install can have an easier name: grep.

[ferventcoder]

Migrated from chocolatey-archive/chocolatey#7

[ferventcoder]

Looks like this has also been requested in NuGet/Home#2391

[ferventcoder]

Requires package indexes first. #820

[ferventcoder]

Side effect of hiding/removing the original issues list is that you can not see those issues anymore - 404.

[gep13]

@ferventcoder that would be where the archiving feature would come into play I think.

[tylerszabo]

I was thinking about how to implement this by policy (rather than waiting for NuGet or custom extensions) and it occurred to me that maintainers could introduce another metapackage. For example if you had a cool app you might do the following:

neatapp depends coolruntime depends popularruntime

Let's say theres another package called otherruntime and that neatapp runs fine with either one. One might want coolruntime to be a virtual package and for a package list to indicate that it can be satisfied by popularruntime or otherruntime and that would be nice, but that requires additional support in NuGet or an extension to resolve.

However, a different structure may be thus:

neatapp depends coolruntime.virtual

popularruntime installs coolruntime.virtual as its installing.

otherruntime installs coolruntime.virtual as its installing.

coolruntime.virtual doesn't actually exist in the feed and so it can only be installed by one of the virtual packages. It can be auto-generated to depend whichever real package was just installed such that the chain looks like:

neatapp depends coolruntime.virtual depends runtimevariantA

or

neatapp depends coolruntime.virtual depends runtimevariantB

This will prevent accidental uninstallation using the existing dependency resolution.

The nuspec for the virtual package

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <id>example.virtual</id>
    <version>0.0.0.0</version>
    <authors>Chocolatey Virtual Package</authors>
    <description>Chocolatey Virtual Package</description>
    <dependencies>
      <dependency id="example" />
    </dependencies>
  </metadata>
  <files/>
</package>

In the event that multiple packages provide the same virtual package some additional cleverness may be needed to make a cleaner uninstall (such as if you want to switch which provider you have).

Right now I accomplish this locally with a stub package that matches the id and version of the feed package I've substituted.

[tylerszabo]

I've further refined this technique using package sources. I use it to allow jre8 to be provided by zulu8.

In the directory C:\ProgramData\chocolatey\virtual I have jre8.8.99999.nupkg that was created with the following nuspec:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>jre8</id>
    <version>8.99999</version>
    <title>jre8 - Virtual package provided by zulu8</title>
    <authors>Virtual</authors>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Virtual package provided by zulu8</description>
    <releaseNotes />
    <dependencies>
      <dependency id="zulu8"/>
    </dependencies>
  </metadata>
  <files />
</package>

I then add the source for my chocolatey packages: choco source add -n=virtual -s="C:\ProgramData\chocolatey\virtual" --priority=1

Now, if I install a package that depends on jre8 it'll grab Zulu 8 and everything is satisfied.

[DJCrashdummy]

in case of virtual packages a smarter way of handling switches (e.g. passing trough by default) would come in very handy.

see proudcanadianeh/ChocoPackages#32 for a very simple case which i encountered...