05.12 Пакетирование

Для семинара понадобится решение предыдущего Д/З или любой проект с приложением на Python, в котором есть:

• сборка перевода
• работающий перевод
• (если успеем) сборка документации
• Этот проект надо скопировать как «Задачу 0»

FIXME не раскрыта тема зависимостей между пакетами. Нужен и разговор о них, и игрушечный пример, где "наш" wheel зависит от другого и притягивает его при установке.

Фактически на практикуме мы решаем будущее Д/З (почти)

«Дистрибутив исходников» (aka sdist) — это содержимое рабочей копии

• + «Уникальные» генераты, которые нельзя изготовить в произвольном окружении (например, растровые картинки из фотошопных исходников).

  • Уникальных генератов следует избегать при условии, что процедура их изготовления автоматизирована (например, doit + pillow)

• + «Информационные» генераты — например, сформатированная HTML-документация по тому, как вести разработку в проекте

• Управляется файлом MANIFEST.in и python -m build --sdist (оно же … -s)

Структура pyproject.toml (при сборке с помощью setuptools + build)

• ArbitTranslate и GradeProject2021

  • FIXME: добавить в GradeProject зависимости

• Минимальный pyproject.toml

• Добавить в dodo.py цель sdist, которая вызывает python -m build --sdist

  • Проверить, что в дистрибутив попадает всё содержимое рабочей копии, и не попадают генераты

«Бинарный дистрибутив» (aka bdist, точнее, bdist-wheel или просто wheel) — это набор для установки и эксплуатации в специальном формате (в действительности — просто zip с пакетом и метаинформацией)

• Модули
• Файлы данных (например, перевод)
• Метаинформация, которую подкладывает система сборки

• Управляется файлом pyproject.html

• Для работоспособности wheel каталоги с данными (например, переводы) должны лежать внутри модуля — см. ArbitTranslate

  • Все не-python файлы указываются в секции [tool.setuptools.package-data]

• Добавить в dodo.py цель wheel, которая вызывает python -m build --wheel и формирует один дистрибутив на клиент и сервер

  • Проверить, что колесо устанавливается в чистое окружение

• Проверить, что клиент и сервер работают, и в сервере работает перевод

FIXME вначале оформить запуск приложения не как точку входа, а "обыкновенно" через python -m (иначе следующая упражненька сразу по двум темам)

Оформить запуск приложения как точку входа

(если успеем) Сгенерировать документацию и добавить её в пакет

• Открыть её посредством webbrowser.open() какой-нибудь новой командой приложения (например, help ☺)

• TODO в 2024-м в Ubuntu были проблемы с запуском (какое-то ограничение по безопасности); ещё сложнее для wsl

Д/З

Задача_1. Пакетирование для MUD (частично сделано в классе, но рекомендуется не торопиться и переделать аккуратно)

• Скопировать решение Задачи_1 с предыдущего занятия. Сделать коммит. Работать на ветке work.

• Реализовать в клиенте команду documentation с вызовом браузера посредством webbrowser.open(), которая показывает сгенерированную документацию

• сделать pyproject.toml, содержащий описание общего пакета с клиентом и сервером

  • описание эксплуатационных зависимостей (cowsay-python и др. используемых пакетов)

  • описание собственно содержимого пакета:

    • файл(ы) *.py

    • скомпилированный перевод

    • txt-файл с дополнительным монстром

    • сгенерированная документация
    • если в состав конкретной реализации входят ещё какие-то файлы, нужные для запуска, то и они
  • указание точек входа для генерации двух сценариев — запуск сервера и запуск клиента

• Предусмотреть описание сборочных зависимостей (например, в секции [dev-packages] Pipfile-а или в requirements-dev.txt)

• проверить установку пакета и запуск клиента и сервера:

  • в двух отдельных pipenv-окружениях

  • в едином pipenv-окружении

  • (в обоих случаях окружение создаётся заново)