# ВИРТУАЛЬНОЕ ОКРУЖЕНИЕ ПО ХАРДКОРУ. ЖИЗНЬ БЕЗ PIP — БЫВАЕТ И ТАКОЕ. Безруков Максим 2k23

2 Безруков Максим Бэкенд разработчик (VK) Душнила t.me/entropax

[TOC] *table of content 3 1. Зачем вообще это всё? 2. Немного истории 3. Про pip 4. Полепим, поварим 5. Cделаем выводы

За что нам всё это? 4 pip опасен? Но почему? - подделка РЕЙТИНГА ПРОЕКТОВ. - опасность вредоносное ПО для бэкдора. - не всё есть в официальном PyPI репозитории - бывает, что пропадает какой-нибудь codecov - мы не читаем deprecation warning :(

Хотелось бы всего и сразу - хочется ставить всё только через пакетный менеджер и репозитории OC - хочется просто жить на systemd сервисах в сервере не используя докер и др. - хочется чтобы мейнтейнеры, когда пакет убирают.. всё дальше работало - хочется чтобы как с докером и pip, но без pip и докера - хочется замороженные во льдах все зависимости и чтоб легко поддерживать - хочется чтобы Армин Ронахер и написал какой-нибудь новый “rye” для этого всего 5

6

7

Немного истории 8 Хотел рассказать про историю от пустоты 1998 сквозь нормальный pip в 2012 и до наших дней с крутыми pipenv/poetry и hatch НО ВСЁ УЖЕ ЕСТЬ. Григорий Петров / Управление зависимостями в Python https://youtu.be/fP8oGx6ZA5o Очень рекоменду посмотреть.

Что же не так с pip и pypi 9 - нет аудита (хотя можно позаботиться самим) - опять новость, что на pypi попали еще N пакетов с названиями, похожими на известные библиотеки и злобным кодом внутри. (и да это работает) - действительно не все пакеты есть в pypi репах - pip и системные зависимости - нет изоляции самой по себе (ну и ладно, есть же venv)

Pip и системные штуки 10 На данный момент, Python Enhancement Proposals фокусируются на зависимостях Python- пакетов между собой, а не от системных пакетов. Ибо цель портативность между различными системами и окружениями. - psycopg2, надо системные штуки - lxml, потребует libxml2 и libxslt - samba или ldb (тащат кучу всякого) - in-house developed libraries (тут вообще страшно) - и др. В большинстве случаем pip выдаст качественную ошибку. ЕСЛИ ПОВЕЗЕТ :) Да-да-да docker шикарное решение этих проблем, но мы тут пытаемся выживать вообще-то.

11 It’s okey *да так и должно быть pip вообще не для этого. И проблемы ли это вообще?

Варианты вариант 1 - уволиться и забугры (не рассматриваем, мы ведь не бежим от проблем) вариант 2 - свой репозиторий с пакетами под проект, свой pypi с аудитом (затратно выходит, но вдруг?) вариант 3 - переубедить начальство и использовать уже pip и docker вариант 4 - слепить из того, что есть вариант X - нанять Армина Ронахера (он всё напишет, лучше чем best-practice) 12

13 *не реклама

Немного фактов и ингредиентов. ● варить будем всё в linux ● допустим нам повезло и мы знаем, OC и архитектуру (это успех) ● кроссплатформенность (это боль в такой ситуации) ● virtualenv(venv) это не докер (нет тут никакой системной изоляции и не должно) ● pyenv != pip (pyenv явно подойдет лучше, чем conda) ● без использования Docker или аналогичных технологий, создание полностью изолированного окружения в Python, включая системные штуки - явно сложно. ● Conda, просто - нет ● venv в python или python в vevn..? ● а как вообще поставить пакет в оружение, если пакетный менеджер работает с системой? 14

Python first 15 Оно скомпилируется на 200+mb много всякого можно убрать. (но сильно уменьшить не выйдет) Можно и с pyenv (но с оговорками) --может не быть (да такое бывает) --shims

Cook vevn питон в окружение или окружение в питон?) 16 Будет работать. пока не трогаем.. (но это не то)

Разбираемся pyenv.conf pyenv.conf: home = /home/PATH_TO_OUR_VENV (статический) УДАЛЯЕМ если очень хочется можно сделать динамическим 17

Разбираемся с activate 18 # starting from approximately line 40 LD_LIBRARY_PATH — это переменная окружения в Unix-подобных операционных системах (Linux / macOS). Нужна компоновщику динамической библиотеки (dynamic linker), чтобы указать, где искать динамические библиотеки для загрузки. Та самая error while loading shared libraries

19

Пакеты 20 ● используем пакетный менеджер(dnf, yum, pacman …) ● смотрим зависимости ● python пакеты обычно с префиксом НО НЕ ВСЕГДА! python3-name ● переносим в окружение нагло или деликатно ● не забываем системные штуки

21 libldb.so libldb.so.2 libldb.so.2.6.1 … те самые системные, их тоже переносим

ОБЯЗАТЕЛЬНО. Сохраняем всю информацию про пакеты и shared штуки requirements.txt всё ещё жив 22

Проверяем Кидаем куда-нибудь нашу frankenstein коробку (С ТОЙ ЖЕ СИСТЕМОЙ И АРХИТЕКТУРОЙ) Конечно - используем git можно в systemd сервис (например запустить нашу django): запускаем - работает. print(“Поздравляю - вы совершили самое настоящее надругательство над venv”) 23

24 shared_libs python pkg libs garbage black box

25 Выводы 1 ● язык != решатель зависимостей != изоляция (Да, бывают исключения вроде cargo rust. Для всего есть свой инструмент) ● минусов больше плюсов (даже если есть скрипты чтобы не копировать руками) ● под каждую архитектуру собирать такое отдельно ● коробку такую можно хранить вообще отдельно от проекта ● больше контроля над неизвестными зависимостями Всё это точно НЕ best practice и вообще антипаттерн.

26 Выводы 2 pyup.io/safety/ NOT FREE it has a user friendly output table or JSON Docker image is available; full reports are available. Даже CI есть github.com/pypa/pip-audit Apache 2.0 license; output table or JSON; and it is easy to implement https://realpython.com/python-package-quality/ катастрофизация ошибка атрибуции антипаттерн используйте pip (просто делайте это правильно) Аудит кода обойдется дешевле. Можно дойти и до виртуального окружения по SSH PEP 517 tool PEP 518 dependencies PEP 621 meta

27 Pip i guess you win

Благодарности 28 Всех благ

Some questions??? 29