[Enhancement] Virtual Packages about chocolatey

[ferventcoder]

See this for more explanation section "3.6 Virtual packages" http://www.debian.org/doc/debian-policy/ch-binary.html

[ferventcoder]

Another resource for explanation: http://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_faq/ch-pkg_basics.en_007.html

[dcjulian29]

This idea should be slightly expanded to include "meta" packages. See https://help.ubuntu.com/community/MetaPackages for an explanation. This would allow packages that don't include anything other than dependencies.

[ferventcoder]

Meta packages are already in chocolatey. Thanks for the suggestion though, I probably need to make the docs highlight that a little more.

[pkahle]

From your comment on your blog, I think you're intending to do this in a very different way than Debian does. It sounds like you're intending to have a package that actually points to other packages, which is a bit fragile compared to the Debian way of doing it (a package "Provides" a virtual package, and other packages "Depends" on the virtual package.

Debian is helped out by having a local package list with metadata about all the packages sitting right there, but from what I can tell, Chocolatey will have to query the server. Not that that's a problem, really, but it might be useful to have a list of virtual packages provided by installed packages. Or maybe it's easy enough to parse all the nupkg files to find them on pkg install.

I haven't looked at Chocolatey's inner workings at all, but I want to make sure you've thought about this before you implement it.

[ferventcoder]

Thought about it quite a bit, but maybe I'm missing the boat with virtual packages. I need to depend on the virtual package, but how does the virtual know what packages satisfy the virtual package requirement?

From what you are saying, it sounds like debian uses some metadata about packages to know whether they are say a "PDFReader" or not. That could get pretty server intensive as chocolatey doesn't keep a local list of packages (which also means it doesn't give a nice "Did you mean 'apt-get curl'?" message either.

Perhaps one could depend on a tag, but that's not reliable on the nuget framework. The current method of implementation I've thought of isn't perfect (doesn't automatically have new packages that meet the virtual requirement), but it's a start... :)

"We never usually go the right direction in the start, only discover it after we've made progress."

Although if you have ideas on how to make it easier to register an application as satisfying a virtual requirement, I'm definitely open to it.

[ferventcoder]

I believe in the blog post you were reading, I was thinking of taking virtual packages to a new level where someone could configure whether they want the ".noinstall" or ".install" version of a tool/application (like nodejs). Other packages would only depend on the virtual package and then the one the user wants would be installed.

[pkahle]

Ok, now you've got me in the weeds.

I've only just looked up how this happens in NuGet, but it seems to me it's not necessarily much slower to add fetching virtual packages when you search for a package by id. The only change would be adding an OR case to the FindPackagesById query to search in the provided packages as well as the actual ID. Yes, it's a hit, but not a huge one, I don't think.

My proposal would be to mirror dependencies in the nuspec file with a different name for virtual packages provided (maybe provides?) so:

Then the command line tool would need to have a way to check if one of the options is installed, then determine which to install, or ask the user, to meet the dependency.

Another related thought that just popped into my mind would be to have a tag that can be used to cleanly do name changes. Debian does this, and it might be useful if you decide to change from *.commandline to *.noinstall.

Now, all of this depends on the relationship between Chocolatey and the core NuGet developers, or Chocolatey's willingness to maintain a fork to implement this. As far as I can tell, it's not really useful in NuGet proper, but I guess it might be useful to try install-package v-dependency-injection-framework or something.

Oh, another thought. I've used v-* for all the virtual packages mentioned so far. If we want to avoid slowdowns and make it more likely to get something like this included in the main NuGet, it could be configured with a virtual package prefix, and only do the search for provides if the package being searched for starts with that sort of prefix. That way we basically add one "if" to the core NuGet process.

OK, I'm kinda liking this, so I may fork NuGet and play around if I have the time.
-----Original Message-----
From: Rob Reynolds [mailto:[email protected]]
Sent: Wednesday, July 25, 2012 14:27
To: Peter Kahle
Subject: Re: [chocolatey] [Enhancement] Virtual Packages (#7)

Thought about it quite a bit, but maybe I'm missing the boat with virtual packages. I need to depend on the virtual package, but how does the virtual know what packages satisfy the virtual package requirement?

From what you are saying, it sounds like debian uses some metadata about packages to know whether they are say a "PDFReader" or not. That could get pretty server intensive as chocolatey doesn't keep a local list of packages (which also means it doesn't give a nice "Did you mean 'apt-get curl'?" message either.

Perhaps one could depend on a tag, but that's not reliable on the nuget framework. The current method of implementation I've thought of isn't perfect (doesn't automatically have new packages that meet the virtual requirement), but it's a start... :)

"We never usually go the right direction in the start, only discover it after we've made progress."

Although if you have ideas on how to make it easier to register an application as satisfying a virtual requirement, I'm definitely open to it.

---

Reply to this email directly or view it on GitHub:
#7 (comment)

[wjk]

Any progress? I seriously 👍 this feature. Also, have you considered implementing an additional API on your Web site to provide <provides> and <replaces> functionality, if you can't fit it into the NuGet package format?

[ferventcoder]

No progress yet. We have other fundamental design issues to finish back up in the rewrite before we could even approach this. But it will be in a special extension of the nuspec format.

[ferventcoder]

This has been moved to chocolatey/choco#858