I've built a tool to write college curricula using the static site generator nanoc. Nanoc is a nice Ruby-based package and it is distributed as a gem.
I installed the gem, and used the "nanoc new" command to create the basic directory structure. Within that directory structure I wrote some custom ruby code, as well as a large number of markdown files to define my first course. Here's the course as it is built.
The code I showed above, in git, corresponds to the result of that work, nanoc + my customizations. There's a bundler file that has to be run to bring in my additional gems as well.
Let's call the individual course "cosi235a.course" and let's call my tool "nanoc-course". I will call the author of cosi235a.course "an author" and I will call the maintainer of "nanoc-course" "me".
What I am seeking help with is a nice design to decouple nanoc-course from cosi235a.course. In other words, I want to separate my customized nanoc based tool from the content of one course.
That way if I want to design the curriculum for a second course I can create that and still pull in updates to the common code. More than that, another author could create a new course on their site, and use nanoc-course for themselves, and benefit from updates I make to the tool.
I've been turning this design question over in my mind and I am not finding an idea I like. Here are the ideas, half baked, so far:
Make nanoc-courss on Git contain everything except all the Markdown, HTML, and other content files. They happen to all live in a subdirectory called ./content according to nanoc. The directory is empty on Git. Add some Rake tasks to create symlinks to a separate directory containing cosi235a.course files. This way the author can work on their content files and at any time do a git pull to any updates to nanoc-course. This is a clean separation but is clunky.
Make nanoc course be a gem to be used with nanoc. In other words, the author installs nanoc, does a gem install (or bundler install) of nanoc-course and add a line or two into nanoc's libs to incorporate the logic. This separation is less complete and requires the author (who is not necessarily a Ruby programmer) to modify code. Also it's fragile with respect to nanoc changes.
Do you have any ideas?
Have the same problem. Option 1 seems the most obvious, but it requires the author to understand the intricacies of git - and I can see that going wrong easily.
I'd tend towards a modification of 2, where you have a custom gem based on nanoc but locking it to a specific version within the gemspec. A "course" would only have to contain a few basic elements, e.g.
/content
/output
Gemfile <== contains your "nanoc-course" gem
Gemfile.lock
Supply a template project for course authors and you'd only have to teach the authors how to use bundler.