Bundles and Packs


Improved dependency handling (bundler) and a new api for view modules (packs)


As of Wagn 1.6, developers can extend Wagn without forking its code by creating a "pack".


"Packs" are ways to extend Wagn's functionality.  In the long term, we envision that a "pack" may refer to several things:

  • "modularized" code that can easily be added or subtracted 
  • a "tradeable" group of configuration cards
  • a combination of the above
At present, a pack is really just that first method -- it's a little code module that uses a simple API to create new views of cards.  
The API is currently in alpha, but there's a lot of power packed into this kind of pack.  You can create special types, special plus cards, and special individual cards.  You can override existing views or create new ones.  You can not only change how a card's content is presented, but also how it's edited.
In fact, all the views of existing types, from Basic to User to Image to Setting, are now handled through this same API.  As are lots of special individual cards, like Recent Changes, *navbox, *account links, and *now.
We'll be adding lots more documentation about how to get started on creating your own packs in coming days and weeks, but in the meantime, feel free to contact the Wagn team through wagn.org if you have questions/ideas.
The other big advance in 1.6 is the use of "bundler" for managing Wagn's software dependencies.  This is a big step towards making installations seamless, as well as towards having Wagn run on the latest (3.x) Ruby-on-Rails releases.


The Wagn 1.6 upgrade involves three key tasks:


1. You must run database migrations for Wagn 1.6 to work.  Please backup your database before migrating in case there are any issues.  

rake db:migrate

Why are migrations necessary?  Because we've updated the handling of "built-in" cards, like *navbox, *now, *version, *account links, etc.  They are now real cards that use the new "card pack" views API.

2. You will need to install, configure, and run "bundler" if you are using git.


  1. Install bundler
    gem install bundler
  2. Use bundler to install / update your other gems.
    bundle install  #WAIT!  This is the basic command, but read the following before running it.
    If you just run that command, bundler will install all the gems Wagn ever uses, including many that you probably don't need, upping the odds that you'll encounter problems.

    So it's best to specify which groups of gems you DON'T need:
    # sample install command for wagns using mysql
    bundle install --without test hosting sqlite postgres
    # sample install command for wagns using postgres
    bundle install --without test hosting sqlite mysql
    Bundler sometimes stumbles on the mysql gem because it doesn't know where the database is stored.  You may find this bundler configuration document helpful in resolving that issue, especially this command:
    bundle config build.mysql --with-mysql-config=XXXXX

FAQ - Foolhardily Anticipated Questions

Why is this necessary?  Wagn is a Ruby-on-Rails application, and it needs gems to run.  Gems are specially-packaged independent ruby programs/libraries.  Bundler is the gem management system used in Rails 3 (on which Wagn will soon run), and it dramatically improves gem maintenance.

Why is this worth it?  Installing gems with bundler can sometimes take a little extra time upfront, but saves a ton of time in the long term.  Bundler stores your configuration preferences in a .bundler file and uses that file to keep your gems up to date with Wagn. It may be hard to notice the headaches you're not having, but this is an investment in many non-headaches in the future.

Do I want those extra "gem groups"?  Not unless you're feeling hard core.  The "test" group is recommended for programmers interested in modifying or extending Wagn.  They are needed to run Wagn tests (rspec, cucumber, etc).  The "hosting" group is not needed to host a wagn site; it includes gems that we use on our hosted wagns and are not needed in most hosting scenarios.  The database groups are only needed if you're using that database.


3. You should also update your submodules (plugins using remotely managed code):
git submodule update --init

It's possible (though not yet confirmed) that migrations directly from 1.5.0 to 1.6.0 may be challenging.  If you have problems, try first migrating to version 1.5.3 and then to 1.6.  And please let me know if this turns out to be true!  If you are migrating from versions earlier than 1.4, you'll almost certainly need to migrate to 1.4 first.  We are planning to improve our migration architecture so that fewer such hops are needed.



+tickets by status


in progress







√- 1. knock off the biggest hoptoad errors

√ 2. the mime type instantiation warnings

√ 3. Slavic's various windows/sqlite patches


Unlike most releases, 1.5.4 will basically be defunct until we run migrations. So we will need to handle downtime, including:


1. a static web message

2. preparing clients for downtime

  --Ethan McCutchen.....Wed Apr 27 10:44:55 -0700 2011

I may have a way to do this without downtime. but I do have a way to put up a maintenance message now.

  --Ethan McCutchen.....Fri May 06 20:02:47 -0700 2011

Unless there is urgency about some of the migrations above, I think I'm going to punt for now and avoid adding any extra complexity to this release. Can do in a point release soon.

  --Ethan McCutchen.....Fri May 06 20:16:51 -0700 2011