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

Question

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

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

В конечном итоге было бы примерно так, как показано в командной строке dos / unix:

$ git clone [URL хранилища] ... $ python setup-env.py ...

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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