Сложный дизайн упаковки кода

Question

Я создал инструмент для написания учебных программ для колледжей с использованием генератора статических сайтов Nanoc. Nanoc - это хороший пакет на основе Ruby, который распространяется как драгоценный камень.

Я установил гем и использовал команду "nanoc new" для создания базовой структуры каталогов. В этой структуре каталогов я написал некоторый пользовательский код ruby, а также большое количество файлов уценки, чтобы определить мой первый курс. Вот курс, как он построен.

Код, который я показал выше, в git, соответствует результату этой работы, nanoc + мои настройки. Есть файл упаковщика, который нужно запустить, чтобы добавить и мои дополнительные драгоценные камни.

Давайте назовем отдельный курс "cosi235a.course" и назовем мой инструмент "нанокурс". Я назову автора cosi235a.course "автором" и назову сопровождающего "нанокурса" "мной".

То, что я ищу помощь, это хороший дизайн, чтобы отделить нанокурс от cosi235a.course. Другими словами, я хочу отделить свой собственный инструмент на основе наноконтента от содержания одного курса.

Таким образом, если я захочу разработать учебный план для второго курса, я смогу его создать и при этом обновлять общий код. Более того, другой автор мог бы создать новый курс на своем сайте и использовать нанокурс для себя, а также получать выгоду от обновлений, которые я делаю для этого инструмента.

Я размышлял над этим вопросом о дизайне и не нахожу идею, которая мне нравится. Вот идеи, наполовину испеченные, пока:

1. Сделайте так, чтобы nanoc-courss на Git содержал все, кроме Markdown, HTML и других файлов содержимого. Все они живут в подкаталоге./content в соответствии с Nanoc. В Git каталог пуст. Добавьте несколько задач Rake для создания символических ссылок в отдельный каталог, содержащий файлы cosi235a.course. Таким образом, автор может работать со своими файлами содержимого и в любой момент сделать git pull для любых обновлений nanoc-курса. Это чистое разделение, но неуклюже.

2. Сделайте нанокурс самоцветом для использования с нанок. Другими словами, автор устанавливает nanoc, устанавливает gem (или пакетную установку) nanoc-Course и добавляет одну или две строки в libo libs для включения логики. Это разделение менее полно и требует от автора (который не обязательно является программистом Ruby) изменения кода. Также он хрупок по отношению к нанокристаллическим изменениям.

Есть ли у вас какие-либо идеи?

Answer 1

Есть такая же проблема. Вариант 1 кажется наиболее очевидным, но он требует от автора понимания тонкостей git - и я вижу, что это легко пошло не так.

Я бы склонялся к модификации 2, где у вас есть собственный гем, основанный на nanoc, но привязанный к определенной версии в пределах гемспека. "Курс" должен содержать только несколько основных элементов, например

/ содержание

/выход

Gemfile <== содержит ваш драгоценный камень "нанокурс"

Gemfile.lock

Предоставьте шаблон проекта для авторов курса, и вам нужно только научить авторов, как использовать bundler.