Possible enhancements

Oct 20, 2010 at 9:08 PM

A few enhancements ideas / suggestions.

  • Dependency only packages. This would be a package that cannot be added directly but can be referenced as a dependency for other packages.
  • Specify dependency repository. Useful for having local packages that have a dependency to a public package.
  • Minor UI tweaks, have icon on install package UI. Add website url.



Oct 20, 2010 at 9:34 PM

Dependency only packages (see http://nupack.codeplex.com/workitem/180)

Dependency repository (see http://nupack.codeplex.com/workitem/223 which should address that scenario. Also see http://nupack.codeplex.com/workitem/188 which is considered for a later version)

For the website URL, see http://nupack.codeplex.com/workitem/167 

The icon on the package UI, we can look at. Thanks!

Oct 20, 2010 at 10:09 PM

Thanks for the reply.

WI 180 doesn't really address what I meant though it does seem useful. I was referring to a package that contains files but those files alone would not be useful. They would however be used as a dependency from 1 or more other packages. You can currently achieve this but the dependency packages show in the list-package command and can also be added so it would make sense to omit the dp's from the view presented to the user. Make sense?

Oct 20, 2010 at 11:28 PM

I still don't understand the scenario. Do you have a concrete example in mind? Something more real-worldish?

Oct 20, 2010 at 11:42 PM

Let's say you have a 2 new packages that you are adding.

Both of these reference a common dll. Rather than adding the common dll to both packages it would make sense to create a package for that common dll and then reference the common dll package as a dependency. However, the common dll package isn't useful on it's own so it would make sense to hide it, prevent it from being added etc (as described previously).

Oct 20, 2010 at 11:52 PM

I understand now, but don't really see much value in the feature. After all, if two packages found the dll useful enough to depend on, why wouldn't a project I'm working on find it useful? For example, maybe I'm working on Package 3 that's going to depend on it. In that project, I may want to install that dependency as a package. :)

Likewise, when I'm writing my package, I need to know the package IDs for the packages I depend on. If they're hidden, how will I find them?

Oct 20, 2010 at 11:55 PM

Also, note that the feed will eventually be much larger, and generally will have many items that most people won't care about.  I don't see the value of going out of our way to hide those packages.  Seems pretty harmless to keep them visible, as as Phil points out, without it they become hard to discover, and someone else might end up recreating a new package for it.

Oct 20, 2010 at 11:57 PM

Fair enough :)

Maybe having a way to filter the list and having assigned categories for packages would make more sense then.

Oct 20, 2010 at 11:59 PM

Oh yes, those things are totally planned.  Hopefully we'll get there soon! :)