Комментарии 19
Скажите, а почему Вы не использовали Fabric? Всё-таки более питоничное решение
Fabric не поможет мне, например, поставить MySQL-python без компилятора; так что собирать пакеты придется в любом случае.
Установкой MySQL-python не Fabric занимается, а pip:
Если в системе будут найдены требуемые h-файлы, за милую душу соберёт. А ещё ведь и easy_install есть, он, кажется, умеет и из бинарных сборок ставить.
run('pip install MySQL-python')
Если в системе будут найдены требуемые h-файлы, за милую душу соберёт. А ещё ведь и easy_install есть, он, кажется, умеет и из бинарных сборок ставить.
Да, но какой смысл ставить libmysql-devel, gcc, glibc-devel и т.д. на боевом сервере, когда можно собрать пакет и парой кликов отправить его на все контролируемые сервера?
Смысл есть, когда проекты живут в изолированных окружениях.
Я вас не совсем понял; можете описать ситуацию в которой центральный контроль над установленными RPM-ами противопоказан?
Самое простое — разные версии какого-либо пакета. К примеру, проекту нужен именно psycopg2==2.4.1 (после этой версии что-то поменяли в механизме транзакций), а в пакете будет самый свежий, 2.4.5.
Теперь ясно. В таком случае, можно настроить Spacewalk Channel, который будет раздавать эту версию и подписать сервер на него.
В любом случае, мы не собираем все пакеты в RPM, а только те которые почти универсальны (и требуют компиляции) PIL, MySQL. Пакеты которые pure Python ставятся через pip v в virtualenv.
В любом случае, мы не собираем все пакеты в RPM, а только те которые почти универсальны (и требуют компиляции) PIL, MySQL. Пакеты которые pure Python ставятся через pip v в virtualenv.
Мне как-то спокойнее, когда проекты разрабатываются в девственно чистых окружениях, изолированных от системного. Это гарантирует, что слепок окружения (pip freeze) покажет те и только те пакеты версий, которые используются в проекте. Удобно :-)
Ради такой независимости пакетов можно и gcc потерпеть, и кучу dev-пакетов с заголовочниками. Лежат себе, каши не простят.
Ради такой независимости пакетов можно и gcc потерпеть, и кучу dev-пакетов с заголовочниками. Лежат себе, каши не простят.
Для себя написал такое: github.com/klen/makesite
Долго думал — «Почему не использовать Fabric?», а потом дошло :)
Успешно пользуюсь makesite на работе.
Долго мучал автора вопросами: великолепно, быстро и развернуто получал ответы с примерами, описаниями.
В общем — спасибо =)
Долго мучал автора вопросами: великолепно, быстро и развернуто получал ответы с примерами, описаниями.
В общем — спасибо =)
Я правильно понимаю, что Makesite сперва надо на целевом сервере установить?
Ага, makesite и fabric совсем разные вещи если честно. Может быть вам поможет вот эта статья с примером: klen.github.com/deploy-setup-ru.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили