05.13 Пакетирование
Для семинара понадобится решение предыдущего Д/З
Автоматизация с помощью doit сборки документации и перевода; работающий перевод
- Решение надо скопировать как «Задачу 0»
Сгенерировать документацию и открыть её посредством webbrowser.open()
Фактически на практикуме мы решаем будущее Д/З (почти)
«Дистрибутив исходников» (aka sdist) — это содержимое рабочей копии
- + «уникальные» генераты, которые нельзя изготовить в произвольном окружении (например, растровые картинки из фотошопных исходников). Уникальных генератов следует по возможности избегать.
- + «информационные» генераты — например, сформатированная HTML-документация по тому, как вести разработку в проекте
Управляется файлом MANIFEST.in и python -m build --sdist (оно же … -s)
Структура pyproject.toml
Добавить в dodo.py цель sdist, которая вызывает python -m build --sdist
- Проверить, что в дистрибутив попадает всё содержимое рабочей копии, и не попадают генераты
«Бинарный дистрибутив» (aka bdist, точнее, bdist-wheel или просто wheel) — это набор для установки и эксплуатации в специальном формате (в действительности — просто zip с пакетом и метаинформацией)
- Модули
- Файлы данных (например, перевод)
- Метаинформация, которую подкладывает система сборки
Управляется файлом pyproject.html
Для работоспособности wheel каталоги с данными (например, переводы) должны лежать внутри модуля — см. ArbitTranslate
Добавить в dodo.py цель wheel, которая вызывает python -m build --wheel и формирует один дистрибутив на клиент и сервер
- Проверить, что колесо устанавливается в чистое окружение
Проверить, что клиент и сервер работают, и в сервере работает перевод
(Если успеем) Оформить запуск клиента и запуск сервера как точку входа
Д/З
Задача_1. Пакетирование для MUD (частично сделано в классе, но рекомендуется не торопиться и переделать аккуратно)
Скопировать решение Задачи_1 с предыдущего занятия. Сделать коммит. Работать на ветке work.
Реализовать в клиенте команду documentation с вызовом браузера посредством webbrowser.open(), которая показывает сгенерированную документацию
сделать pyproject.toml, содержащий описание общего пакета с клиентом и сервером
описание эксплуатационных зависимостей (cowsay-python и др. используемых пакетов)
- описание собственно содержимого пакета:
файл(ы) *.py
- скомпилированный перевод
txt-файл с дополнительным монстром
- сгенерированная документация
- если в состав конкретной реализации входят ещё какие-то файлы, нужные для запуска, то и они
- указание точек входа для генерации двух сценариев — запуск сервера и запуск клиента
Предусмотреть описание сборочных зависимостей (например, в секции [dev-packages] Pipfile-а или в requirements-dev.txt)
- проверить установку пакета и запуск клиента и сервера:
в двух отдельных pipenv-окружениях
в едином pipenv-окружении
- (в обоих случаях окружение создаётся заново)