Есть ли другие хорошие альтернативы zc.buildout и/или virtualenv для установки зависимостей, отличных от python?

Question

Я являюсь членом команды, которая собирается запустить бета-версию веб-сайта на основе python (Django) и сопутствующего набора бэкэнд-инструментов. За последние несколько лет сама команда удвоилась в размере от 2 до 4, и мы ожидаем дальнейшего роста в ближайшие пару месяцев. Одной из проблем, которая нас запугила, является то, что все ускоряются с точки зрения настройки их среды разработки и установки всех правильных яиц и т. Д.

Я ищу способы упростить этот процесс и уменьшить его ошибка склонна. Как zc.buildout, так и virtualenv выглядят так, как если бы они были хорошими инструментами для решения этой проблемы, но оба, похоже, сосредоточены прежде всего на проблемах, связанных с python. У нас есть несколько небольших подпроектов на других языках (в частности, Java и Ruby), а также множество расширений python, которые должны быть скомпилированы изначально (lxml, MySQL-драйверы и т. Д.). Фактически, один из самых больших шипов на нашей стороне получил некоторые из этих расширений, собранных против соответствующих версий разделяемых библиотек, чтобы избежать segfaults, malloc-ошибок и всех подобных проблем. Это не помогает, что из 4 человек у нас есть 4 разных среды разработки - 1 леопард на ppc, 1 леопард на Intel, 1 ubuntu и 1 окно.

В конце концов, что было бы идеально было бы то, что работает примерно так, из командной строки DOS/UNIX:

$ мерзавца клон [URL хранилища] ... $ питон setup-env.py . ..

, который затем выполняет то, что делает zc.buildout/virtualenv (копирует/связывает интерпретатор python, обеспечивает чистое пространство для установки яиц), затем устанавливает все необходимые яйца, включая установку любых родных зависимостей разделяемой библиотеки, устанавливает проект ruby , проект java и т. д.

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

В идеале, я хотел бы получить инструмент, который выполнит это, чтобы быть написанным в/extensible через python, так как это (и всегда будет) lingua franca нашей команды, но я открыт для решений на других языках.

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

Answer 1

В принципе, вы ищете кроссплатформенный программный/пакетный установщик (на линиях apt-get/yum/etc.) Я не уверен, что что-то подобное существует?

Альтернативой может быть указание списка пакетов, которые необходимо установить через систему управления пакетами, такую ​​как Fink или DarwinPorts для Mac OS X, и иметь скрипт, который устанавливает среду сборки для собственного код?

Answer 2

Я продолжал исследовать этот вопрос, так как я разместил вопрос. Похоже, что есть некоторые попытки решить некоторые из потребностей, которые я изложил, например. Minitage и Puppet, которые используют разные подходы, но оба могут выполнить то, что я хочу, хотя Minitage не указывает явно, что поддерживает Windows. Не имея более лучших вариантов, я постараюсь сделать одно из этих или просто расширенное индивидуальное использование zc.buildout для наших нужд, но я все еще чувствую, что там должны быть лучшие варианты.

Answer 3

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

Answer 4

Кукольный не поддерживает (легко) мир Win32. Если вы ищете механизм развертывания, а не только инструмент «dev setup», вы можете рассмотреть возможность поиска в ControlTier (http://open.controltier.com/), который имеет кросс-платформенное решение с открытым исходным кодом.

Помимо этого вы смотрите на «корпоративное» программное обеспечение, такое как BladeLogic или OpsWare, и, как правило, возмутительное предложение для предлагаемой функциональности (мое мнение, очевидно).

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

Answer 5

Утилита Setuptools может быть больше того, что вы ищете, чем вы понимаете. Если вам нужна специальная версия lxml для правильной работы на MacOS X, например, вы можете поместить URL-адрес в соответствующее яйцо внутри ваш setup.py и setuptools загрузите и установите его в среду ваших разработчиков по мере необходимости; ему также может быть сказано загрузить и установить определенную версию зависимости из контроля версий.

Это говорит о том, что я склоняюсь к использованию созданной скриптами виртуальной среды. Достаточно просто создать файл кикстарта, который устанавливает какие бы пакеты вы ни зависли, а затем загружать виртуальные машины (или производственное оборудование!) Против него, при этом марионетное или подобное программное обеспечение делает другое администрирование (добавление пользователей, настройка служб [где ваша база данных поступает из ?], и т.д). Это особенно удобно, когда ваша производственная среда включает в себя несколько машин - просто создайте сценарий генерации нескольких виртуальных машин в своей удобной маленькой изолированной подсети (для этого я использую libvirt + kvm, а kvm недоступен на всех платформах, на которых работают разработчики on, qemu, безусловно, есть, или вы можете делать то же, что и я, и иметь небольшое количество жестких VM-хостов, разделяемых несколькими разработчиками).

Это избавляет вас от головных болей поддержки платформ N - у вас есть только одна виртуальная платформа для поддержки - и означает, что ваш процесс развертывания, как определено файлом кикстарта и кукольным кодом, используемым для установки, является источником -контролировать и проходить через QA и просматривать процессы так же, как и все остальное.

Answer 6

Я всегда создавать develop.py файл на верхнем уровне проекта, и есть также packages каталога со всеми из .tar.gz файлов из PyPI, что я хочу, чтобы установить, а также включен распакованный копию virtualenv, который готов запустите прямо из этого файла. Все это входит в контроль версий. Каждый разработчик может просто проверить багажник, запустить develop.py, а через несколько минут будет готова виртуальная среда, включающая все наши зависимости, в точности, какие версии используют другие разработчики. И он работает, даже если PyPI не работает, что очень полезно на этом этапе истории этой службы.