Low friction principle

Aug 21, 2010 at 11:44 PM

One thing that I see based on tweets and feedback on nu is the simplicity of making a package. I think that's a key thing here that needs to be held as a core principle. If there's friction in building these things (complicated config files, long setup, involved build process) then no matter how cool the concept is, people will reset it.

Currently this is what one does to make a gem for nu:

  1. Get the binaries for a release
  2. Organize the binaries in a lib folder then any subsequent folders (net-1.1, net-2.0, etc. if the project uses them)
  3. Create a one line VERSION file of the version you're going to push (product version + optional YYYYMMDD push date)
  4. Create the .gemspec file (about 10 lines, I just have a boilerplate I use)
  5. gem build gemname.gemspec
  6. [optional local test] gem install gemname-version.gem
  7. gem push gemname-version.gem
  8. [optional] Update webpage with links to source code, mailing list, wiki, etc.

NuPak needs to hopefully be at least this simple so lets see if we can aim for that.

I'm thinking even a cmdline/gui/powershell cmdlet to do step 4 (with prompting) so users don't even have open up a .nuspek file (but that's after v1 maybe or a weekend project).

At a bare minimum we need the cmdline tools to build and push the package.

Aug 22, 2010 at 1:07 AM

The current philosophy we have right now when building new functionality is this:

  • Design end to end experience(s) we want users to have
  • Create an API in the core assembly that does the bulk of the work
  • Create different clients that consume the core API in different ways (cmd/powershell/web ui)

Right now we're trying to figure out what our version of a .gemspec file looks like. Once we have that then we can determine what the pushing a package means (atompub?). Another thing is that we don't only have binaries in our packages, we have tools and content. The workflow I imagine would be the easiest is:

  1. Get the bits needed to build the release
  2. Run "nupak build package.nuspek" and end up with package.nupak
  3. [optional local test] nupack install package
  4. Go to site or feed and upload or run a command similar to  "nupak push package.nuspek" -> push the package to the default server, or I imagine you'd be able to specify one.

We definitely want simplicity to be a primary goal though.

Aug 22, 2010 at 3:40 AM

As far as putting together the .nuspek file, I think most people will end up just starting from some existing one, much like the 'boilerplate' you mention.

So concretely, for the common case of a nupak that only contains assembly references, it should be pretty easy to build.

We'll need to build a bunch ourselves, so if the process is too complex, we'll feel the pain before others have to!