'Reference-only' packages

Mar 14, 2011 at 8:14 PM

This is something that's been discussed a fair bit lately on twitter and private emails relating to NHibernate, so I'd like to move the discussion to this forum. The term 'Reference-only' is very confusing, as it could mean two totally different things:

  1. A package that only contains references: this has always been supported, and is often referred to as a meta-package. e.g. 'Rx-All' is one such package.
  2. A package that is only usable as a reference from another package: this is not supported today. The idea is that some packages like NHibernate or WebActivator don't make much sense to be installed directly. Instead, they make sense as dependencies of other packages that depend on other things as well. Those other packages that depend on them could be meta-packages. Maybe we can call these reference-only packages, as the term has not yet been used in NuGet.

Hopefully, this will clarify some of the confusion around this!

Now let's use this thread to further discuss those 'reference-only' packages, and exactly how we want to design this in NuGet.

Mar 14, 2011 at 8:23 PM
These reference only packages would not show up in the normal query is the difference I keep hearing. I like this idea granted they are not magical. In other words, I could still run a switch to see them. Otherwise people who are trying to learn how to write NuGet packages may be confused even more.
Mar 14, 2011 at 8:23 PM
How about the term abstract package? That terminology makes more sense to quite a few people.
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder
Mar 14, 2011 at 8:33 PM

Agreed that they should not be completely hidden, but only hidden by default.

Interestingly, one case where you have to see them is when you write a new package that use them. e.g. if you want to write a new packages that uses WebActivator, you first have to install WebActivator directly.

Note that they could come into play in a completely different scenario: deprecated packages. You don't want new users to find them, but they should still exist to avoid breaking existing things. At least I think it's the same concept as what's needed for WebActivator. I'd rather not have two different concepts for those two cases if possible.

'abstract package'? Hmmm, not quite sold on that but could be convinced if others like it. :) How about something really explicit like 'hidden packages'?

Mar 14, 2011 at 8:37 PM
How about "packages you can't see but can install if you know where to find them packages"? ;)

In the case of deprecated packages, are we talking about the idea of a yanked bad package? That to me is truly something you can't get to and should be blocked from installing (except of course with a switch if you really need to).
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder



Mar 14, 2011 at 8:41 PM

Not necessarily bad, but deprecated. Perfect example is happening now, with the EF team wanting to rename the next drop of their super popular EFCodeFirst package to EntityFramework. We still want EFCodeFirst to be installable as others depend on it, but we don't want new users to accidentally use it instead of the new one. In fact, their yet older EFCTP4 package is still on the feed, occasionally causing confusion.

Mar 14, 2011 at 8:41 PM
For packages you should not install directly, the developer in me really likes the word 'abstract.'
It jives for me instantly versus a reference package, as I didn't understand the difference between it and a meta package based on terminology construct alone.

Perhaps there is a better word out there for it.

Deprecated packages to me would be something wholly different and probably should be treated with something different.
Why? You would never put deprecated in a package you are creating.
The idea of deprecated comes long after a package has been released.
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Mar 14, 2011 at 8:44 PM
Exactly my point on how deprecated is different than "reference" packages.

We should probably start a completely different discussion on how that should be so we don't continue two flows here.
Mar 14, 2011 at 8:48 PM

virtual packages? :)

Mar 14, 2011 at 8:50 PM

The usage is different, but are they really that different in term on nuget behavior? i.e.

  • Neither of them show up in the gallery, or in the VS Dialog/PowerShell search results (by default)
  • Both of them can be installed by explicit reference

It feels like from an end user's stand point, they are not that different. The difference is mostly for package authors, who should not reference deprecated packages (though existing package may do that of course).

How about: esoteric packages or intangible packages? ;)

Mar 14, 2011 at 8:51 PM
Nice.
Mar 14, 2011 at 8:56 PM
So walk me through how I, as a package owner would write an abstract/virtual/reference package.

Now walk me through how I as a package owner would write/mark a deprecated package. <- the nuspec doesn't change here.

I agree that the concepts of how the system behaves with them are the same...but are we going to reach into a published package and change the spec? Am I missing something here from the package owner experience? I don't want nuget to change my nuspec if I deprecate a package. That is something I would expect to be outside of my package completely. I would want it to be on the gallery itself. Meaning it is stored somewhere else.

Am I explaining this very well (because I can see the difference pretty well in my mind)?
Mar 14, 2011 at 8:57 PM

A few more options:

In-Private packages.

Incognito packages

Mar 14, 2011 at 9:33 PM

Rob, that's a good point: in one case you want that to be in the nuspec, while in the other it should be a gallery bit. One solution is to allow the 'hidden' bit to be set in the nuspec, and also allow overriding it from the gallery for packages that are already published.