Показаны сообщения с ярлыком pip. Показать все сообщения
Показаны сообщения с ярлыком pip. Показать все сообщения

16 февраля 2015 г.

Upgrade your pip & virtualenv now

Странно, что несмотря на очень давний выход pip 6.0 и virtualenv 12.0, многие Python разработчики все еще сидят на более ранних версиях этих незаменимых утилит.

Мой вам совет - обновляйте свой pip & virtualenv сейчас же!

Главная причина - это, конечно, встроенный в pip, толковый и включенный по умолчанию менеджер скачанных зависимостей. Да, и раньше можно было пользоваться опцией --download-cache или конфигом:

[install]
download_cache = /path/to/pip-cache

в ~/.pip/pip.conf, но старый менеджер загрузок был скорее дополнительным, чем полностью готовым к использованию механизмом. Более детальный ход разработки менеджера загрузок хорошо продемонстрирован на GitHub.

Из остального в новом pip ведется проверка версий относительно PEP 440, а значит, что, к сожалению, лучше попрощаться с версиями: X.Y-dev, которые хоть и не попадают на PyPI, но очень часто используются в разработке.

13 июля 2012 г.

Копируем виртуальные окружения с помощью virtualenv-clone

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

Для начала еще раз поясню саму идею. Есть репозиторий, есть деплоймент сервис, который для каждого коммита может генерировать код/базы данных/бутстрап проекта/что-угодно и выдавать на гора результат в виде готового для доступа URL-адреса. Для вытаскивания кода и расположения его в определенной директории могут использоваться разные подходы, как впрочем и для работы с базой данных. Но бутстрап проекта для уже готовой базы данных хочется сделать просто:

$ virtualenv --distribute --system-site-packages env
$ . env/bin/activate
(env)$ pip install -r requirements.txt
(env)$ deactivate
$ cp project/settings_local.py{.deploy,}

И вроде бы все работает, но чем больше становится зависимостей и чем больше коммитов приходит на деплой тем система начинает работать все медленней и медленней и постоянно задыхается на этапе pip install -r requirements.txt. Не хорошо!

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

Первая идея была очень интересной: а что если новое виртуальное окружение создавать в активированом основном виртуальном окружении? YO DAWG, не иначе. В итоге получилось так же если б мы просто создали новое виртуальное окружение, локальные зависимости основного окружения не были доступны в новом окружении.

Второй идеей было использование --relocatable опции для основного окружения. Результат: после копирования окружения и установки зависимостей, зависимости обновлялись и в основном окружении, а это нам совсем не нужно.

Третьей идеей было таки спросить у гугла "python virtualenv copy" на что гугл выдал мне ссылку на virtualenvwrapper, откуда я путем быстрого рисёрча исходников попал на virtualenv-clone и радостно захлопал в ладоши - то, что нужно!

Так что задача полноценного копирования виртуальных окружений решается просто:

$ sudo pip install virtualenv-clone
$ virtualenv-clone env_base env_new

зы. Еще одним решением для ускорения установки зависимостей была, есть и остается опция --download-cache для pip'а. Но хотелось именно решить вопрос с копированием виртуальных окружений.

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

23 января 2010 г.

Разворачиваем проект при помощи virtualenv и pip

Наверное, нет смысла подробно останавливаться на том, что такое virtualenv или pip, про эти трендовые понятия питоньего мира написана уже не одна статья. Так что сегодня, я просто поделюсь способом разворачивания проекта основуясь на этих технологиях.

Итак, на самом деле все просто. Для начала надо создать новое виртуальное окружение, а затем установить туда все зависимости. Также было бы неплохо получить Makefile со всеми необходимыми целями, которые будут облегчать работу с проектом.

Конечно, все это можно делать и руками для каждого следующего проекта. Благо запоминать там немного:

$ virtualenv ENV

да:

$ pip install -E ENV -r REQUIREMENTS.pip

где REQUIREMENTS.pip - файл со всеми необходимыми зависимостями для проекта. Ну а потом прописать прямо в Makefile или в Makefile.def путь к "новому" Python'у, в нашем случае это может выглядеть как-то так:

PYTHON=ENV/bin/python

Но, когда новые проекты начинают сыпаться как из рога изобилия хочется автоматизировать все эти действия. Для этого я на коленке написал bootstrap скрипт. Разберемся с тем, что он делает.

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

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

В-третьих, скрипт создат для Вас новое виртуальное окружение, если оно еще не создано. По умолчанию, это виртуальное окружение создатся с опциями --no-site-packages --unzip-setuptools.

В-четвертых, скрипт попытается создать Makefile, используя шаблонный файл Makefile.template, который должен быть ранее создан в директории проекта.

В-пятых, скрипт установит все зависимости, находящиеся, по умолчанию, в файле REQUIREMENTS.pip и сохранит все скачанные архивы с питоньими пакетами в ENV/src. Формат файлов зависимостей описан в документации к pip.

Собственно все. После обновления зависимостей или шаблона Makefile - просто выполните bootstrap.py еще раз and have fun.

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