Cloning, copying, RYO servers

Aug 31, 2010 at 11:25 PM

I was thinking about things on the way home today. If I was a user I would want to be able to setup my own package server. I might want to do this because I have low bandwidth and don't want every developer pulling down stuff from the internet, or I want to control the packages or I have my own packages I want to build.

In the case of wanting to setup my own server I stand it up (assuming there's one to build from like a simple MVC sample we provide) but now need packages. I don't want to build them, I just want existing ones to use.

So I can see two things we can provide.

  1. A set of test packages that anyone can use and are not real packages but gives you something to work with. Call it Northwind for NuPack (I'm sure Hanselman will love that). Something like 5 class libraries that don't do anything but are packaged separately. a could be independent, b could rely on c, d could rely on b, and e could rely on d (note: I screwed up the dependencies as I typed this but the idea is to have 1 standalone, 1 package that depends on a single package, and 1 that relies on 2 packages that in turn 1 of them relies on another). That way users could grab that zip of .package files, put them on a share or their server and start working with packages from a "get used to this". Pull down a they get it added to their project. Pull down another and it gets all the dependencies. Maybe have one that shows web.config changes and another that has script support and another with a custom .ps1. In any case, some set of fake test packages that not only exercise the dependency system but also shows off some other aspects of the system and lets users play with it without actually breaking or having to mess with real packages that might be volatile and change from version to version.
  2. The ability to clone a single package or an entire server from one server to another. I see this as something like Clone-Package -Source SourceUri -Destination DestinationUri [-All] [-Package MyPackage]. This would effectively do a site to site transfer (like an FTP transfer) or some other way (a simple wget like download/upload). So if I found a server with a package I wanted I could just grab it or if I wanted to say grab all packages from a server I could do that. The criteria could be extensive to do things like wildcard matching (grab all packages that start with A or use some kind of regex). This is probably a v2 or even v3 feature but I think for v1 users need the ability to download a .nupack file from a server so they can use it on their own.
Sep 1, 2010 at 12:09 AM

Yes, I like #2.  Note that today, you can 'clone' selected packages simply by installing them, since that keeps them into the solution level folder.  So technically, you can create a feed straight from the packages that got copies solution level.  But the ability to bring down many packages at once is something we don't have today (other than the dependency scenario).

Sep 1, 2010 at 1:18 AM

Well, you're not really cloning a package. All you're doing is installing the output of one. If I wanted to setup my own server (even a file share) I need the .nupack file, not the exploded contents. Also installing the package doesn't bring down the .nuspec file.

Sep 1, 2010 at 1:22 AM

Actually, the act of 'installing' a package does bring up the original package file in addition to what it expands (this is needed for uninstall, so we know if user modified files).  So effectively, it builds up a mini-repository as it goes, even though that was not technically a goal.

Sep 1, 2010 at 1:27 AM

Oh, didn't realilze that. Guess I never looked into the packages folder after installing them. It thought only the output would be there, not the original package. Good to know (and I'll update the docs, been poking away at them each night as I find time).