Использование git для разработки плагинов - PullRequest
Новая
       107

Использование git для разработки плагинов

2 голосов
/ 10 февраля 2011

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

Сначала я подумал, что мне нужноподмодуль git, затем настроить суперпроект, а затем объединить поддерево, но я не уверен, что какой-либо из них действительно подходит.

У меня есть проект (Ева), иЯ пишу расширения для него , которые необязательны .Поэтому, если бы вы вытащили копию Eva из Github, она не содержала бы дополнительных плагинов, но вы могли бы получить их отдельно и использовать их.

Дополнительные расширения находятся в той же структуре каталогов, что и Eva.Пока все просто ... 

Eva
 |
 --- system/
 --- events/
   |
   --- core_events
 --- tests/
   |
   --- core_tests

Extension A
 |
 --- events/
   |
   --- [extension A]
 --- tests/
   |
   --- [extension A tests]

Сегодня вечером я хотел добавить тесты к этим расширениям, и в настоящее время они хранятся в отдельном каталоге за пределами моего локального репозитория Eva git.Чтобы запустить эти тесты, мне действительно нужно, чтобы эти расширения находились в том же каталоге, что и Eva, события зависят от базовой системы.

Eva
 |
 --- system/
 --- events/
   |
   --- core_events
   --- [extension A]
   --- [extension B]
 --- tests/
   |
   --- core_tests
   --- [extension A tests]
   --- [extension B tests]

Я мог бы скопировать файлы проекта Eva в каталог репозитория расширений, но если я изменю исходный код Eva, то мне придется продолжать копировать эти изменения по всему.

Должен ли я продолжать это неуклюженастроить или есть более изящный способ, которым git может приспособиться к этому?

Может быть, мои требования противоположны другим вопросам.Мои расширения - это подпроект Eva, и мне нужно время от времени извлекать обновления из репозитория Eva.

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

Не уверен, что слияние поддеревьев тоже подходит, мне никогда не придется тянуть проект расширений в основной проект Eva.

Ответы [ 3 ]

3 голосов
/ 20 февраля 2011

Я думаю, что ваш лучший вариант - попытаться изменить макет проекта таким образом, чтобы каждое расширение было более автономным, IE находится в своем собственном каталоге, скажем, /extensions.

При запуске framework / testrun,сканировать этот каталог и динамически загружать расширения.Таким образом, вы не только облегчаете разработку и работу с git, но и облегчаете различные варианты упаковки, т.е. тарболы IE.Это позволяет пользователю легко видеть, какие расширения используются.

Затем вы могли бы также позволить сторонним разработчикам легко разрабатывать расширения «вне дерева», используя выбранную ими VCS.

0 голосов
/ 18 февраля 2011

Я думаю, что это может быть достигнуто с помощью git-хука, настроенного таким образом, что каждый коммит (или push) либо в ядро, либо в репозитории расширений (хранятся отдельно) вызывает обновление каталога тестирования релиза, содержащего актуальные копииобоих.Не имея знаний VonC по этому вопросу, я могу, однако, перенаправить вас, например, manpage и Глава 5 книги сообщества git .

ВНа самом деле, еще более простым решением было бы установить этот каталог тестирования релизов с использованием копий программных ссылок обоих репозиториев (cp -rs).К сожалению, в этом случае вы должны помнить о добавлении новых программных ссылок всякий раз, когда добавляете новые файлы в любой репозиторий.

0 голосов
/ 10 февраля 2011

Как насчет простого сценария оболочки, который находится в корневом каталоге часового проекта, назовите его plugin_manager, который позволяет пользователю перечислять установленные плагины, перечислять доступные плагины на сервере проекта, а также загружать и устанавливать новые?Это может быть более интуитивно понятным для конечного пользователя, чем спор подмодулей git, особенно если они не знакомы с Git.

Загрузка и запуск тестов могут быть просто одним из шагов, которые скрипт выполняет, когдапользователь запускает $ plugin-manager download foo-module

Для хорошего примера шаблона ознакомьтесь с документацией для Команды Drush (оболочка Drupal) .

...