Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Отчего я ненавижу virtualenv и pip

Anna | 15.06.2014 | нет комментариев
 не разделяю общей любви к virtualenv (дальше — venv) и pip. Я считаю, что они лишь вносят неразбериху и больше того — вредят. Python программисты Почаще каждого не соглашаются со мною, да и venv pip дефакто считается эталоном в python сообществе. Так как я понимаю, насколько голословными звучат мои высказывания, решил написать сей трактат. Безусловно, я изредка пускаюсь спорить на эту тему и в реальной жизни; ну нравится мне заводить людей и отслеживать, как страстно они остаивают свою позицию. Но при мне неизменно казалось, что словесно я не могу обосновать свою позицию в полной мере. Следственно взамен того, Дабы непрерывно пытаться вербально доказывать свою точку зрения, я решил написать эту статью, чтобы потом легко показывать её людям. Может быть тогда некоторые со мною согласятся, потому что теперь не согласен примерно никто. А может напротив, как только мои аргументы будут всецело осознаны, найдутся те, кто их аргументированно опровергнет. Так либо напротив, я буду рад любому варианту становления событий.

venv и иллюзия изоляции

Изоляция и легко воспроизводимое чистое python-окружение безо каждых спрятанных зависимостей от стержневой операционной системы это, определённо, отличная вещь. Основная цель venv — предоставление комфортного метода изоляции на ярусе python’а. Но здесь не всё безупречно: для тех пакетов питона, которые зависимы от системных библиотек, изоляция осуществляется лишь Отчасти, распространясь только на python-составляющую этих пакетов. Если разработчик в курсе этого — всё еще не так нехорошо, но вот если нет — он может столкнуться с серьёзными и неясными ему задачами.

Полные способы изоляции приводят к избыточности venv

Есть несколько способов изоляции каждой файловой системы. Самый полный, но массивный метод — это применение виртуальной машиной под гипервизором. Такую функциональность обеспечивает ряд программ, таких как Vagrant. С иной стороны существуют легковесные решения, скажем chroot, либо легковесные контейнеры, работающие на ярусе операционной системы, скажем на Linux это LXC. Причём LXC может применять copy-on-write файловую систему как бы btrfs для создания среды окружения с большей скоростью и меньшими расходами дискового пространства, чем даже в случае с venv.

venv это антипаттерн развёртывания

Я Ощущаю раздражение некоторых читателей при упоминании таких спецтехнологий как LXC. Да, на практике мы не неизменно можем обеспечить совместимость нашей целевой среды окружения с LXC. И не неизменно мы можем предоставить LXC требуемые ей права суперадмина (и чай всё это лишь для того, Дабы легко развернуть наше приложение!)
Но я считаю, что и venv тоже не подходит для развёртывания. Отчего? Как упоминалось в начале, мпортируются в существующие планы и, собственно, сами эти планы. Те разработчики, которые пишут лишь приложения не абсолютно понимают все особенности создания пакетов, следственно недолго думая легко «захардкоживают» каждый выбор используемых ими модулей в своё приложение, легко перечисляя их в requirements.txt, чай это так комфортно! Эти разработчики Почаще каждого легко советуют пользователям установить venv, а после этого накатить в него свой пакет в него командой pip install -r requirements.txt.

В итоге мы имеем некоторое число python разработчиков, которые считают requirements.txt панацеей от всех задач. Они даже никогда не узнают о существовании setuptools. Их легко покоряет кажущимся простым тупое перечисление ссылок на нужные пакеты, лежащие где-то на в недрах интернета: на сайтах либо в системах контроля версий. Меня обескураживает их святая убежденность в «фантастической» практичности этого подхода и вытекающем отсель желании пропагандировать применение virtualenv pip как связки необходимых инструментов для всех и всякого.

URI в качестве путей к зависимостям это отстой

setuptools разрешает вам указать имя и нужную версию пакета, тот, что по умолчанию скачивается с Pypi. Pypi обеспечивает индексацию, но вы можете сделать и свой личный индекс (в виде примитивных HTML страниц) и настроить извлечение информации из них в первую очередь, не с сайта Pypi. Кто бы ни разработал эту спецтехнологию, он пытался предоставить разработчику вероятность привязываться к именам пакетов, а не физическому их местоположению и не веб-протоколу. И он мыслил верно.

Если вы в requirements.txt указываете путь к локальному файлу либо к лежащему на каком-нибудь сайттарболлу, по факту вы захардкоживаете эту ссылку. правда в данном случае лучшим выходом было бы применение репозитория пакетов. Тот, что дозволил бы людям, скажем, настроить в их локальной сети зеркала на него. Помимо того вы не можете указать минимальную версию, лишь только точную нынешнюю. А в один очаровательный день тот самый файлик с пакетом переместится либо удалится, в всеобщем пропадёт, и код неожиданно перестанет трудиться. Абсолютно видимо, что мы этого не хотим, чай так?

Что ж, есть иной метод. Давайте указывать зависимости таким методом:
git https://github.org/my/stupid/fucking/package#egg=1.2.3

Но он требует от пользователя иметь на компьютере git, помимо того pip’у доводится выкачивать полную копию репозитория. Помимо того, в различие от этого примера, Почаще люди даже не применяют версионную нотацию (1.2.3 в примере) и полагают, что стабильная версия должна лежать в ветке master. Всё это уныло. Я знаю, что теперь модно ставить всё подряд прямо из систем контроля версий, но «хардкордить» эти URL в ваш план? И без того спорное решение, становящееся вовсе неоправданным, если всё дозволено сделать верно, легко немножко попотев над положительной настройкой setup.py.

Если вам по нраву pip freeze, с вами что-то не так

У меня отлично получается отслеживать свои зависимости и руководить ими. Я делаю это с поддержкой pip freeze. Одни пользуются это командой, Дабы быть уверенными, что они не упустили никакие зависимости во время цикла разработки. Если вы предполагаете, что pip freeze выдаёт вам список зависимостей как раз для вставки в requirements.txt (тот, что, напомню, не необходим) — тогда вы легко используете -no-site-packages (тот, что тоже не необходим) при создании нового venv и каждый комплект зависимостей всё равно получается глобально-системным, а не питоньим. Ох, но помимо того, в этом случае нет метода узнать, какие из ваших зависимостей установлены напрямую, а какие подтянуты другими.

С иной стороны дозволено, найдя, что эти зависимости порушили вашу среду окружения, попытаться легко пересоздать её. Но с venv pip это займёт у вас целую вечность (напомню, необходимо будет пересобрать всё и каждая). В то время как с LXC CoW и с теснее собранными пакетами (всех зависимостей, с которыми вы не трудитесь в данный момент) в бинарные eggs, вы найдете недостающие зависимости как на ярусе системы, так и непринужденно питоньи, дюже стремительно.
В целом pip freeze не такая уж плохая команда, всё дело в том, что люди слишком Зачастую считают её необходимой, не принимают во внимание её недочеты и применяют не по назначению.

Завершение

Это мой критикующий, при этом всецело субъективный и в чём-то может даже спорный, обзор полезности как программ virtualenv и pip, так и программерской культуры, сложившейся вокруг них. Мне дюже нравится питон как язык, но поменьше — как платформа, потому что она фрагментирована разными эталонами распространения пакетов и эталонами процесса разработки. Лично в моём случае это приводит к тому, что я трачу слишком много времени на борьбу с питоном, нежели на работу с ним. Я регулярно общаюсь с различными мудрыми людьми, которые откровенно верят, что venv и pip обеспечивают всё, что им необходимо для разработки, совместной работы и развёртывания готовых приложений. Я же во время разработки не использую ни venv, ни pip.
И я верю, что эта статья, как минимум, докажет читаталю, что дозволено и необходимо понимать правило работы этих программ и при этом скептически относиться к ним.

От переводчика:
Разработчикам, работающим под Windows: самостоятельно от того, решили вы отказаться от pip либо легко ищете метод устанавливать некоторые пакеты, которые не хотят сходу ставиться с pip (скажем падающие с оплошностью unable to find vcvarsall.bat), а на сайтах разработчиков пакетов, скомпилированные версии не предоставляются, могу порекомендовать Удивительный сайт, собирающий под своим крылом всевозможные скомпилированные пакеты во всевозможных версиях: Unofficial Windows Binaries for Python Extension Packages

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

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB