Packs+API+organization

Here's an example of a file in a pack:

local/packs/mypackname/sets/type/company.rb

Let's break that down.  "local/packs" (in your Wagn root directory) is currently the default value for "pack_dirs", which can be configured in wagn.yml.  You can set that to whatever you like.  We may eventually shift to "vendor".  We'll almost certainly be making greater use of gems.  The organization may shift a bit, but the general pattern will remain.

Next is "mypackname".  This is to make it easy to have lots of packs coexist together.

Because packs are currently exclusively limited to set configurations, the "sets" may prove superfluous, but we have it there currently to leave room for the possibility that there may be some things we want in packs that we can't fit into our set framework (eg new set patterns).

Here's where it gets more interesting.  The next two names ("type" and "company") are both important, because they are codenames. 

You may know that every card in the wagn database has a name (which can be changed) and an id (which can't).  Cards that are referred to in code also have a codename.   Any reference to a card in code should use the codename. Not only does this name not change, it must be the same on any wagn that uses the code in question (whereas the name and ids may be entirely different across wagns).

In the case of the pack file structure, the codenames are based on the names by which we refer to sets.  For example, the set of all Company cards is represented by Company+*type.  The codename of *type is "type" (this is sometimes called the "set pattern"), and the codename of company is company.  Because packs are grouped by set pattern, the order is reversed in the file structure.

All sets have a set patter.  In fact, some sets are nothing but a set pattern.  For example, *all, *all plus, and *star are all set classes with no plus. Pack files for these "simple sets" follow a similar pattern to other sets, but the final file name itself does not have to correspond to a codename; it is just ignored.

local/packs/mypackname/set/all/ignore_me.rb

Note that Wagn's built-in packs follow the same essential structure, and can be found here:

wagn-app/sets/
wagn-app/sets/all/base.rb
wagn-app/sets/type/basic.rb

 There are several other kinds of files we will want to support, eg

wagn-app/sets/type/company.js
wagn-app/sets/type/company.coffee

Those two clearly have a role in the pack code.  Less clear is whether we will support other kinds of assets (CSS, images, etc), or whether we will focus on means to integrate them into packs as cards.  Best guess for now: they will be included here, but part of the installation process will be importing them as cards.

We should also support pack-specific tests.  my first guess is that this will look something like:

local/packs/mypackname/spec/sets/type/company_spec.rb

And then there's the need to support gems, probably with a Gemfile in the pack root.