Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
// Все, что я напишу ниже это мое мнение, если у кого-то это вызывает боль — рекомендую выключить компьютер, и пойти почитать книжку.
RVM Намного функциональнее venv'a. Да, тоже изменяется текущее окружение, Но в целом удобнее.
Bundle и Gem, отличии от мира питона где зоопарк решений в руби Bundler используется везде. В pip нам на работе приходится иметь 2 файла; install_requirements, dev_requirements, при этом install_requirements обрабатывается sed'ом перед деплоем.
Я не знаю над чем там смеются .Net'щики, но каждый раз когда мне надо скачать новый .Net чтобы запустить 5 мегабайтную программу я не смеюсь.
Что касается деплоя: зачем там venv и rvm? Не нужен зоопарк версий на продакшен сервере. Bundle, да, нужен. pip насколько я знаю несправляется без venv если надо несколько приложений.
По удобству инструменты в мире питона отстают от руби и прочее на световые года. Впрочем не уступает питону только php и go.
RVM Намного функциональнее venv'a. Да, тоже изменяется текущее окружение, Но в целом удобнее.
Bundle и Gem, отличии от мира питона где зоопарк решений в руби Bundler используется везде. В pip нам на работе приходится иметь 2 файла; install_requirements, dev_requirements, при этом install_requirements обрабатывается sed'ом перед деплоем.
Я не знаю над чем там смеются .Net'щики, но каждый раз когда мне надо скачать новый .Net чтобы запустить 5 мегабайтную программу я не смеюсь.
Что касается деплоя: зачем там venv и rvm? Не нужен зоопарк версий на продакшен сервере. Bundle, да, нужен. pip насколько я знаю несправляется без venv если надо несколько приложений.
По удобству инструменты в мире питона отстают от руби и прочее на световые года. Впрочем не уступает питону только php и go.
Я не знаю над чем там смеются .Net'щики, но каждый раз когда мне надо скачать новый .Net чтобы запустить 5 мегабайтную программу я не смеюсь.Вообще говоря фреймворка достаточно самого последнего. Вы же не удивляетесь, что периодически приходится обновлять версию ruby?
А смеются потому что дотнету (равно как и яве) не нужна изоляция от системы. Просто не нужна и всё. Работает подход «всё своё ношу с собой». Положил набор managed dll-ок в дистрибутив (именно в дистрибутив, так-то всё извлекается NuGet-ом), и знаешь, что заведётся как надо. А нативных зависимостей у дотнета практически никогда нет (клиент MySql, например, полностью на C#, без всяких libmysqlclient и прочего мусора). А если и есть, то компилировать всё равно ничего не надо, так как нативные сишные функции импортируются через P/Invoke с поздним связыванием. В принципе, всё то же самое относится к Java, разве что там JNI вместо P/Invoke.
Так на ruby и не пишут настольные приложения. Мой то вброс был на тебу десктопных приложений на .Net. например ваш клиент для vpn'a работает neo4en в ubuntu.
В руби тоже можно FFI использовать для вызова сишнего кода без какой либо компиляции. И тот же JNI в случае с jRuby. Что касается Java — опять зоопарк: maven2, maven3, gradle, sbt, ant и наверное еще 10 штук. Без своего хранилища артефактов вообще сложно существовать. Но «все свое ношу с собой» мне нравится.
> (клиент MySql, например, полностью на C#, без всяких libmysqlclient и прочего мусора)
Это исключительно следствие того, что C# быстрее ruby и python'a. У нас в python проекта едиственная нативная зависимость это libmemcached.
> Вообще говоря фреймворка достаточно самого последнего.
Тогда почему меня установлено все доступные фрэимворки для Win 7? Руками я их не ставил никогда. И еще куча VC++ redistributable установлено начиная с 2005 года.
> А смеются потому что дотнету (равно как и яве) не нужна изоляция от системы.
В руби и питоне тоже можно без изоляции обойтись если зависимостями заниматься так же как в Java и .NET. А больше одной версии ruby надо только некоторым разработчикам и CI.
В руби тоже можно FFI использовать для вызова сишнего кода без какой либо компиляции. И тот же JNI в случае с jRuby. Что касается Java — опять зоопарк: maven2, maven3, gradle, sbt, ant и наверное еще 10 штук. Без своего хранилища артефактов вообще сложно существовать. Но «все свое ношу с собой» мне нравится.
> (клиент MySql, например, полностью на C#, без всяких libmysqlclient и прочего мусора)
Это исключительно следствие того, что C# быстрее ruby и python'a. У нас в python проекта едиственная нативная зависимость это libmemcached.
> Вообще говоря фреймворка достаточно самого последнего.
Тогда почему меня установлено все доступные фрэимворки для Win 7? Руками я их не ставил никогда. И еще куча VC++ redistributable установлено начиная с 2005 года.
> А смеются потому что дотнету (равно как и яве) не нужна изоляция от системы.
В руби и питоне тоже можно без изоляции обойтись если зависимостями заниматься так же как в Java и .NET. А больше одной версии ruby надо только некоторым разработчикам и CI.
касается Java — опять зоопарк: maven2, maven3, gradle, sbt, ant и наверное еще 10 штук.
Там или оно поверх maven так или иначе или аналоги make. Фактически же лучше использовать maven и те системы что эксплуатируют его инфраструктуру тем или иным способом. В этом случае со сборкой, зависимостями и деплоем проблем не возникает.
Это исключительно следствие того, что C# быстрее ruby и python'a. У нас в python проекта едиственная нативная зависимость это libmemcached.
Это исключительно в следствие того что C# писался с оглядкой на Java. А там как-то либы все за редким исключением написаны на java.
> Там или оно поверх maven так или иначе или аналоги make. Фактически же лучше использовать maven и те системы что эксплуатируют его инфраструктуру тем или иным способом. В этом случае со сборкой, зависимостями и деплоем проблем не возникает.
Это если я начинаю новый проект. Я вот начал sbt использовать, начальник использует maven, потом решили все под gradle перевети. Они конечно мощные инструменты, но maven требует столько лишнее текста, что никакого желания нет его использовать.
> Это исключительно в следствие того что C# писался с оглядкой на Java. А там как-то либы все за редким исключением написаны на java.
Так и Java на медленная. Был бы .Net медленный использовали бы FFI. У нас на работе есть проект у которого в зависимостях javacv. Самая отвратная бибилиотека которую я только видел, а подключить нормальную не хотят потому, что не православно.
Это если я начинаю новый проект. Я вот начал sbt использовать, начальник использует maven, потом решили все под gradle перевети. Они конечно мощные инструменты, но maven требует столько лишнее текста, что никакого желания нет его использовать.
> Это исключительно в следствие того что C# писался с оглядкой на Java. А там как-то либы все за редким исключением написаны на java.
Так и Java на медленная. Был бы .Net медленный использовали бы FFI. У нас на работе есть проект у которого в зависимостях javacv. Самая отвратная бибилиотека которую я только видел, а подключить нормальную не хотят потому, что не православно.
Они конечно мощные инструменты, но maven требует столько лишнее текста, что никакого желания нет его использовать.
maven так многословен в силу того что он не просто система сборки и управления зависимостями. По этой причине требует чтения документации и вдумчивого написания конфига.
У нас на работе есть проект у которого в зависимостях javacv. Самая отвратная бибилиотека которую я только видел, а подключить нормальную не хотят потому, что не православно.
Использование либы через JNI как правило дает много головняка и проблем при развертывании.
Тогда почему меня установлено все доступные фрэимворки для Win 7?У вас там две версии рантайма (.NET 2.0/.NET 4.0) и обновления базовой библиотеки классов (3.0/3.5/4.5). Если у вас установлен 3.5, то он спокойно запустит приложение для 2.0. Mono вот вообще сиренево, что там и где, запускает бинарники, собранные под любой дотнет.
например ваш клиент для vpn'a работает neo4en в ubuntu.Наш клиент VPN сейчас вообще написан на Qt 4.7. Со старым начались проблемы из-за того что наркоманы из каноникал отменили системный трей, не сделав при этом для GtkStatusIcon слоя эмуляции, как для QSystemTrayIcon (sni-qt). Кстати, какие именно затруднения у вас возникают? Я ни разу за последнее время проблем не испытывал с ним.
В руби и питоне тоже можно без изоляции обойтись если зависимостями заниматься так же как в Java и .NETНо этого никто не делает. В результате развёртывание приложений на ruby превращается в ад, особенно если не знать про существование RVM и копипастить команды из инструкции по установке.
> Кстати, какие именно затруднения у вас возникают? Я ни разу за последнее время проблем не испытывал с ним.
Очень не стабильно работал в отличи от openvpn'a.
> Но этого никто не делает. В результате развёртывание приложений на ruby превращается в ад, особенно если не знать про существование RVM и копипастить команды из инструкции по установке.
Как это не делает? При правильном деплои bundle всегда делает «бандл» зависимостей. А rvm нужен только если надо несколько версий руби в одном окружении, что весьма плохая идея, зачем делать шаред хостинг на руби? О каком аде идет речь? Один раз настроить capistrano, и разворачивай любое приложения сколько хочешь.
Очень не стабильно работал в отличи от openvpn'a.
> Но этого никто не делает. В результате развёртывание приложений на ruby превращается в ад, особенно если не знать про существование RVM и копипастить команды из инструкции по установке.
Как это не делает? При правильном деплои bundle всегда делает «бандл» зависимостей. А rvm нужен только если надо несколько версий руби в одном окружении, что весьма плохая идея, зачем делать шаред хостинг на руби? О каком аде идет речь? Один раз настроить capistrano, и разворачивай любое приложения сколько хочешь.
Вы, наверное, имели в виду ivy, а не ant.
Вообще ibiblio довольно хорошо работает. Другое дело, что maven, когда я последний раз с ним работал, напрочь не имел возможности автоматического разрешения версий.
Вообще ibiblio довольно хорошо работает. Другое дело, что maven, когда я последний раз с ним работал, напрочь не имел возможности автоматического разрешения версий.
Не нужна. Самый последний вполне в состоянии запустить те, что от предыдущих. Там суть в чём:
1) всего было 3 версии рантайма основного 1.0, 2.0 и 4.0. 3.0, 3.5 и 4.5 — это обновления базовой библиотеки классов, то есть если у вас в системе есть .NET 3.0, а приложению нужен 2.0, то оно спокойно запустится. С версиями рантайма несколько сложнее. 2.0 в состоянии запустить приложения собранные под 1.0/1.1 (я ни одного такого не видел, правда, но тем не менее), а вот между 4.0 и 2.0 есть набор несовместимых изменений, которые несущественны, но тем не менее для того чтобы .NET 4.0 согласился запустить exeшник, собранный под .NET 2.0, необходимо чтобы у того в манифесте было чётко прописано, что новый рантайм его не удивит.
Как-то вот так.
1) всего было 3 версии рантайма основного 1.0, 2.0 и 4.0. 3.0, 3.5 и 4.5 — это обновления базовой библиотеки классов, то есть если у вас в системе есть .NET 3.0, а приложению нужен 2.0, то оно спокойно запустится. С версиями рантайма несколько сложнее. 2.0 в состоянии запустить приложения собранные под 1.0/1.1 (я ни одного такого не видел, правда, но тем не менее), а вот между 4.0 и 2.0 есть набор несовместимых изменений, которые несущественны, но тем не менее для того чтобы .NET 4.0 согласился запустить exeшник, собранный под .NET 2.0, необходимо чтобы у того в манифесте было чётко прописано, что новый рантайм его не удивит.
Как-то вот так.
Как-то получил я Ruby-проект, установил RVM, сделал cd в директорию проекта… и увидел, как крашится терминал. Опытные рубисты, наверное, сразу догадались бы, что дело в .rvmrc, в котором были прописаны криквые комманды, но представьте моё удивление, когда обычный, абсолютно безопасный cd начал стабильно убивать консоль.
RVM обеспечивает свою функциональность за счёт магии с перехватом комманд. Кому-то нравится магия, кому-то нет. Кто-то любит Rails за автоматическую генерацию кода, а кто-то предпочитает Django с его явными зависимостями. Это вопрос предпочтений, но никак не отставания.
RVM обеспечивает свою функциональность за счёт магии с перехватом комманд. Кому-то нравится магия, кому-то нет. Кто-то любит Rails за автоматическую генерацию кода, а кто-то предпочитает Django с его явными зависимостями. Это вопрос предпочтений, но никак не отставания.
Какая еще магия перехвата комманд? Обычная манипуляция с PATH там. А то, что cd начал крашить терминал это какая-то магия, если делать cd в каталог с .rvmrc, rvm сначала спросит использовать его или, в крайнем случае выдаст ошибку, что такая версия руби не устновлена. В вашей ситуации видать какую-то не понятную магию туда добавили.
Ок, я активирую RVM, делаю cd в директорию с .rvmrc. Откуда терминал знает, что ему нужно прочитать .rvmrc?
Обычная манипуляция с PATH в chruby и, в некоторой степени, в rbenv. А rvm переопределяет команду cd.
Ок, возможно, я нечётко выразился. RVM заставляет стандартные команды выглядеть иначе. cd — это хороший пример. Когда я меняю директорию в терминале, я ожидаю, что я просто сменю директорию. Я не ожидаю, что будет выполнен какой-то скрипт. Это магия, вклинивание в стандартные комманды. Это может быть удобно, да, но также может вести к неожиданным последствиям.
virtualenv также манипулирет PATH-ом, но не делает ничего неожиданного. Он обещает сделать песочницу со своим питоном и библиотеками, и делает именно это. Он не пытается заменить что-то существующее, если его об этом специально не попросить. Кто-то может считать это недостатком, но Python Zen недвусмысленно намекает, что explicit is better than implicit.
virtualenv также манипулирет PATH-ом, но не делает ничего неожиданного. Он обещает сделать песочницу со своим питоном и библиотеками, и делает именно это. Он не пытается заменить что-то существующее, если его об этом специально не попросить. Кто-то может считать это недостатком, но Python Zen недвусмысленно намекает, что explicit is better than implicit.
Опционально:
Перегружает команды оболочки, такие как cd. Это опасно и может привести к ошибкам.
Перегрузка cd опциональна. Я искал суммарно почти 8 часов за последний месяц, чтобы найти проект, который перегружает cd — и что вы думаете? Не нашёл. В любом случае, RVM предоставляет возможность смотреть на тот код, который будет исполнен при запуске cd до момента его исполнения и выбирать, доверять ему или нет.
Но было включено по умолчанию несколько лет назад, когда я использовал rvm. Собственно, по Вашей же ссылке: habrahabr.ru/post/131968/#comment_4389739
Если сейчас в rvm нет тех проблем, которые были пару лет назад — это просто чудесно, я рад за использующих rvm.
Если сейчас в rvm нет тех проблем, которые были пару лет назад — это просто чудесно, я рад за использующих rvm.
От исполняемого .rvmrc rvm ушёл в сторону декларативного .ruby-version, в нём же поддерживаются и gemset'ы.
Многие любят ставить RVM и на продакшне. Сталкивался несовместимостей версии Ruby с определёнными библиотеками, причём даже среди MRI, что уж говорить, когда какой-то worker запускается с JRuby, а основное приложение — на 1.9.3, тут без RVM никак.
Сам по себе RVM тот ещё инструмент, его можно сравнить с бензопилой, в инструкции к которой написано «не пытайтесь остановить полотно руками или половыми органами», потому что такие случаи случались. Отучить людей делать system-wide install просто невозможно.
Bundler и RubyGems хороши, но пока дело не доходит до сотни установленных gem'ов. Стоит посмотреть протокол, по которому они работают с rubygems.org, и становится реально страшно. Новый Dependency API просто перекладывает работу на сервер, создавая дикую нагрузку, при этом заниматься улучшениями, в отличии от неимоверного числа коммиттеров в Rails, никто не хочет.
Сам по себе RVM тот ещё инструмент, его можно сравнить с бензопилой, в инструкции к которой написано «не пытайтесь остановить полотно руками или половыми органами», потому что такие случаи случались. Отучить людей делать system-wide install просто невозможно.
Bundler и RubyGems хороши, но пока дело не доходит до сотни установленных gem'ов. Стоит посмотреть протокол, по которому они работают с rubygems.org, и становится реально страшно. Новый Dependency API просто перекладывает работу на сервер, создавая дикую нагрузку, при этом заниматься улучшениями, в отличии от неимоверного числа коммиттеров в Rails, никто не хочет.
Гм, и ни слова про buildout
buildout — довольно глючная вещь. Не раз сталкивался с тем, что он просто отказывается работать, без объяснения причин (невнятная ошибка, по которой непонятно, куда копать). А также с тем, что не ставились новые версии зависимостей (явно прописанные в конфигурации), не применялись патчи (возможно, проблема конкретной реализации recipe, но от этого не легче ), и т.д. и т.п.
как в старом добром анекдоте:
"- что-то мне, индейцы, ваш вождь не нравится…
— не нравится — не ешь."
Да, инструмент не идеален.
Да, он подходит для большинства случаев.
Нет, негативные эмоции — плохие помощники в любом деле.
"- что-то мне, индейцы, ваш вождь не нравится…
— не нравится — не ешь."
Да, инструмент не идеален.
Да, он подходит для большинства случаев.
Нет, негативные эмоции — плохие помощники в любом деле.
Во-во, а потом спрашивают, зачем нужен девопс. Девопс нужен, чтобы установка чего-либо в систему не была «особо согласовываемым действием».
Пользуюсь buildout, согласен с автором.
Как-то сильных фактов автор не привел, осуждает venv за то, что он уродует ему шибэнги, а pip не работает с яйцами. Для 99% использования они подходят хорошо, а остальное можно допилить (да и нельзя сделать универсальный инструмент на все случаи жизни).
Единственное, с чем могу согласить с автором, так это не полной изолированности venv, его нельзя взять, упаковать и перенести на другой сервер :(
Да что там на другой сервер, недавно обновлял os x и venv созданые под 10.8 перестали работать под 10.9, т.к. питон поменял версию с 2.7.3 на 2.7.5 и не все либы почему-то он стал видеть. Пришлось создавать новый venv и ставить все заново, правда заняло это 5 минут
Единственное, с чем могу согласить с автором, так это не полной изолированности venv, его нельзя взять, упаковать и перенести на другой сервер :(
Да что там на другой сервер, недавно обновлял os x и venv созданые под 10.8 перестали работать под 10.9, т.к. питон поменял версию с 2.7.3 на 2.7.5 и не все либы почему-то он стал видеть. Пришлось создавать новый venv и ставить все заново, правда заняло это 5 минут
Distribute 0.7.3: «This package is a simple compatibility layer that installs Setuptools 0.7+.»
Проект Distribute, который развивался как форк setuptools, официально больше не поддерживается, его код слит обратно с setuptools. Теперь остались только setuptools и pip. Distutils2 тоже загнулся.
Подскажите, как бороться с такой проблемой:
Иногда проходит команда, а иногда — выдает такую ошибку.
# pip install rosinstall-generator
Downloading/unpacking rosinstall-generator
Could not fetch URL https://pypi.python.org/simple/rosinstall-generator/: There was a problem confirming the ssl certificate: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:550)>
Will skip URL https://pypi.python.org/simple/rosinstall-generator/ when looking for download links for rosinstall-generator
Could not fetch URL https://pypi.python.org/simple/: There was a problem confirming the ssl certificate: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:550)>
Will skip URL https://pypi.python.org/simple/ when looking for download links for rosinstall-generator
Cannot fetch index base URL https://pypi.python.org/simple/
Could not fetch URL https://pypi.python.org/simple/rosinstall-generator/: There was a problem confirming the ssl certificate: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:550)>
Will skip URL https://pypi.python.org/simple/rosinstall-generator/ when looking for download links for rosinstall-generator
Could not find any downloads that satisfy the requirement rosinstall-generator
Cleaning up...
No distributions at all found for rosinstall-generator
Storing complete log in /root/.pip/pip.log
Иногда проходит команда, а иногда — выдает такую ошибку.
Стоит последний pip2, openssl и поставил ca-certificates. Не помогает.
Пришел на работу со своим ноутом, там установилось. В общаге вылезает ошибка, что выше.
Пришел на работу со своим ноутом, там установилось. В общаге вылезает ошибка, что выше.
Спасибо, но не работает. Выдает Error <urlopen error [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed> while getting pypi.pytho)
А как эту проверку вообще отключить?
А как эту проверку вообще отключить?
У меня на текущий момент всего пару пунктов вызывают недовольство:
Я не скажу что у меня огромный опыт в других пакетных системах для питона, но контейнеры и виртуалки для изоляции python окружения в большинстве случаев все же считаю оверкилом, а buildout за кратковременное знакомство совсем не зацепил. То что не нужны рутовые права (в большинсве случаев), не нужно менять (ломать) основную систему (в большинсве случаев), можно быстро развернуться считаю хорошим плюсом.
- чтобы поставить пакет нужно установить libSOMETING-dev или тулзу необходимую для сборки, причем можно долго и упорно выяснять это по всем зависимостям
- virtualenv можно сломать установкой/обновлением/удалением пакетов или обновлением системы и в эти моменты нужно догадаться что что-то пошло не так и пересоздать окружение
- он никак не защищает от того что автор пакета может удалить свой пакет или конкретную версию с pypi
- скачивание и сборка пакетов может занимать много времени, для частых развертований это может быть довольно критичным
Я не скажу что у меня огромный опыт в других пакетных системах для питона, но контейнеры и виртуалки для изоляции python окружения в большинстве случаев все же считаю оверкилом, а buildout за кратковременное знакомство совсем не зацепил. То что не нужны рутовые права (в большинсве случаев), не нужно менять (ломать) основную систему (в большинсве случаев), можно быстро развернуться считаю хорошим плюсом.
Если билдить нативные пакеты прямо с готовым virtualenv, то все проблемы решаются:
1) Нужно только на билд машине
2) В нативном пакете прописываем жесткие зависимости от системных пакетов
3) Свое зеркало pypi или whl
4) Cвое зеркало pypi или whl или просто включить cache в ~/.pip/pip.conf
Лично меня напрягает ровно одна вещь — идеологичесая:
Пакетные менеджеры были в частности созданые еще и для того, чтобы каждая баблиотека была установлена 1 раз. Скажем если вам нужен python-django, то вы его ставите 1 раз для всех проектов. Иначе получается .NET (фреймворк у нас на каждой машинке, а все остальное носим с собой).
Но может это только личные терзания.
1) Нужно только на билд машине
2) В нативном пакете прописываем жесткие зависимости от системных пакетов
3) Свое зеркало pypi или whl
4) Cвое зеркало pypi или whl или просто включить cache в ~/.pip/pip.conf
Лично меня напрягает ровно одна вещь — идеологичесая:
Пакетные менеджеры были в частности созданые еще и для того, чтобы каждая баблиотека была установлена 1 раз. Скажем если вам нужен python-django, то вы его ставите 1 раз для всех проектов. Иначе получается .NET (фреймворк у нас на каждой машинке, а все остальное носим с собой).
Но может это только личные терзания.
Все же для dev окружения многое остается.
Как я понял Вы имеете ввиду зависимости от системных питоновских пакетов, если так, то получается, что специфические версии используемых яиц также должны быть собраны, или же собираем всесь проект с virtualenv и установленными зависимотсями в пакет OS?
За
Как я понял Вы имеете ввиду зависимости от системных питоновских пакетов, если так, то получается, что специфические версии используемых яиц также должны быть собраны, или же собираем всесь проект с virtualenv и установленными зависимотсями в пакет OS?
За
whl спасибо.Да. Вот, например, если вы используете MySQL-python, то понятно что на билд машине вы должны поставить libmysqlclient-dev.
Собираем все через virtualenv + pip install -r reqs.txt и в получившемся пакете жестко прописываем libmysqlclient18 (= 5.5.34)
Если вдруг злой админ решит поставить что-то другое или удалить этот пакет, то он получит уведомление от пакетного менеджера, что нужно решить конфликт. В этом случае для вас не будет неожиданностью ситуация и вы будете осознанно действовать. Других способов сломать virtualenv я не знаю, но не исключено что они есть.
Вот кстати еще ссылок на подумать:
hynek.me/talks/python-deployments/ вот этот вот чувак считает, что все нужно раскладывать в нативные пакеты.
И даже предлагает тулзу, которая умеет кастовать пакеты из python/gem/другие в deb/rpm/другие (https://github.com/jordansissel/fpm)
Не лишено смысла, но ооочень трудозатратно. Потому что фактически у вас будут посчи все пакеты новые относительно stable репозитория. И все придется собрать, хоть и один раз. Ну и не трудно догадаться, что все зависимости придется расписывать самому (а это могли бы сделать за нас разрабы либ, но им тоже влом :)
А вот ребята из Mozilla docs.services.mozilla.com/server-devguide/release.html другого мнения.
Если коротко, то они фактически пихают все в virtualenv и пакуют его вместе с кодом в нативный пакет (у них это rpm).
Не по феншую, зато топорно просто.
Собираем все через virtualenv + pip install -r reqs.txt и в получившемся пакете жестко прописываем libmysqlclient18 (= 5.5.34)
Если вдруг злой админ решит поставить что-то другое или удалить этот пакет, то он получит уведомление от пакетного менеджера, что нужно решить конфликт. В этом случае для вас не будет неожиданностью ситуация и вы будете осознанно действовать. Других способов сломать virtualenv я не знаю, но не исключено что они есть.
Вот кстати еще ссылок на подумать:
hynek.me/talks/python-deployments/ вот этот вот чувак считает, что все нужно раскладывать в нативные пакеты.
И даже предлагает тулзу, которая умеет кастовать пакеты из python/gem/другие в deb/rpm/другие (https://github.com/jordansissel/fpm)
Не лишено смысла, но ооочень трудозатратно. Потому что фактически у вас будут посчи все пакеты новые относительно stable репозитория. И все придется собрать, хоть и один раз. Ну и не трудно догадаться, что все зависимости придется расписывать самому (а это могли бы сделать за нас разрабы либ, но им тоже влом :)
А вот ребята из Mozilla docs.services.mozilla.com/server-devguide/release.html другого мнения.
Если коротко, то они фактически пихают все в virtualenv и пакуют его вместе с кодом в нативный пакет (у них это rpm).
Не по феншую, зато топорно просто.
Заместо него я предпочитаю использовать easy_install
Once you easy_install, there's no easy uninstall
Резюмируюя:
1. локальные пакеты есть добро
2. virtualenv не даёт полной изоляции для локальных пакетов
3. подходящих альтернатив нет
1. локальные пакеты есть добро
2. virtualenv не даёт полной изоляции для локальных пакетов
3. подходящих альтернатив нет
Почти все описанные автором проблемы происходят из того, что pip используется на продакшене. В случае если приложение собирается в пакет для целевой операционной системы, все операции с pip и venv происходят на билд-машине, а админу/клиенту приезжает все уже в готовом виде и только с необходимыми зависимостями.
Много правильных моментов в статье, но автор не предлагает никаких путей их решения.
Подозреваю, что Вам так и не удалось переубедить коллег в спорах, раз даже целую статью написали.
А все потому, что при всей неидельности pip + venv в разы ускоряет разработку и deploy, а эмоциональной-идеологический батхерт отнимает время и нервы.
А все потому, что при всей неидельности pip + venv в разы ускоряет разработку и deploy, а эмоциональной-идеологический батхерт отнимает время и нервы.
Интересно знает ли автор, что venv включили в стандартную библиотеку Python 3.3.?
PEP 453 его точно добъет.
Только что на канале одного питоновского проекта:
Косвенное свидетельство в пользу того, что люди считают, что «pip и venv это отличная связка».
Кстати, как называется, когда узнаешь о чем-то и почти сразу сталкиваешься с этим независимо?
a: hi
a: ?how can I update X if I use pip to install it?
b: a: does normal pip install -U X work?
a: i would like to update
a: i dont try with command
a: i'll try one moment
a: b: I get this message with this command
a: Could not find any downloads that satisfy the requirement X in /usr/local/lib/python2.7/dist-packages
a: Downloading/unpacking X
a: Cleaning up…
a: No distributions at all found for X in /usr/local/lib/python2.7/dist-packages
a: Storing complete log in /root/.pip/pip.log
b: a: are you using virtualenv?
a: no
Косвенное свидетельство в пользу того, что люди считают, что «pip и venv это отличная связка».
Кстати, как называется, когда узнаешь о чем-то и почти сразу сталкиваешься с этим независимо?
Интересно, как автор относится к virtualenvwrapper. :)
Вообще-то также.
Virtualenvwrapper только делает создание и работу с виртуальным окружением удобнее. Вы же не можете использовать virtualenvwrapper без virtualenv:)
Sets PATH and changes your prompt. If you find this exciting, you’ve been living under a rock. Same goes for virtualenv wrapper. .NET developers on Windows are mocking you.
Virtualenvwrapper только делает создание и работу с виртуальным окружением удобнее. Вы же не можете использовать virtualenvwrapper без virtualenv:)
virtualenv + pip это **не** система дистрибуции софта. Это способ разработки. На выходе все равно должен получиться .tar.gz с кучей *.wheel-ов или нечто другое инсталлябельное.
А если так, то разрабатываться можно так как удобно — никто тут ничего не навязывает. Тот же кто использует virtualenv+pip для обновления продакшна — дурак и всё.
А если так, то разрабатываться можно так как удобно — никто тут ничего не навязывает. Тот же кто использует virtualenv+pip для обновления продакшна — дурак и всё.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я ненавижу virtualenv и pip