Модули Perl и Ruby в одном репозитории?

Question

Я начал работать над новым модулем Perl и решил, что хочу также создать его версию для Ruby (как только я закончу версию Perl). Люди склонны делать отдельные репозитории для каждого языка? Или положить их в тот же репозиторий?

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

Что считается лучшей практикой в ​​этой ситуации?

FWIW, я использую git.

РЕДАКТИРОВАТЬ : я должен быть более ясным здесь. Это не модули в смысле git submodules. Это модули, которые будут отправлены в CPAN и RubyGems. Пользователи этого проекта, вероятно, будут устанавливать его через cpan или gem, а затем использовать / требовать его обычным способом.

Answer 1

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

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

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

Answer 2

Мой опыт в этом случае состоит в том, чтобы иметь 2 меньших репозитория git для каждого из модулей, и любое клонирование одной ветви в репозиторий потребительских проектов делает это довольно простым. Другой способ - создать «голого» клона из репозитория модуля в репозитории потребительских проектов, а затем просто обновлять его по мере развития каждого модуля. потребительский проект должен игнорировать введенные репозитории.

как только другие разработчики клонируют модуль A и / или B, он может просто перейти к потребительскому проекту, если позволяют разрешения. это или за или против зависит.