0

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:

  1. 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.

  2. 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?

halfer
  • 19,824
  • 17
  • 99
  • 186
pitosalas
  • 10,286
  • 12
  • 72
  • 120
  • 1
    Don't put links to your code in your question. Summarize the code and needed data, to the minimum required to duplicate the problem or explain your question. Without that you're expecting us to chase down the information needed to help you. See http://sscce.org/ – the Tin Man Aug 10 '13 at 03:00

1 Answers1

2

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.

ferrisoxide
  • 167
  • 5