02.20 Использование pip и venv, редактирование истории в git

Новое правило по отчёту о посещаемости:

• Все упражненьки делаем в каталоге «задачи № 0», т. е.

  •    $ mkdir -p `date "+%Y%m%d"`/0
       $ cd `date "+%Y%m%d"`/0
       $ # hack-hack-hack
       $ git add .
       $ git commit -a -m "Classes (или что-то такое)"
       $ git push

pip и venv

• Работа с venv

  • структура каталога
  • Что такое activate

  • попробовать создать venv, войти в него и написать программу, которая использует модуль, отсутствующий в это venv

• Pip и ensurepip

  • Работа с pip — установка, удаление, список

    • Замечание о бедности зависимостей

  • Поиск через pypisearch или pip-search

• Работа с pipenv (введение)

  • Создание, вход и установка

  • Найдите, где pipenv держит базовый каталог ☺

• ВНИМАНИЕ - при работе в созданном изолированном окружении не следует запускать программы из idle, т.к. эта среда написана на python и тянет с собой лишнее

• Использование стороннего пакета на примере python-cowsay

  • Установка
  • Использование в программе
  • Документация vs исходный код

  • Написать примитивную утилиту (как в Д/З к лекции, но выводящую только корову по имени и сообщение)

  • Скачайте любимую корову отсюда, подсуньте её в соответствующий каталог убедитесь, что работает.

Редактирование истории

• Создание ветки от выбранного коммита
  • на занятии ветка нужна, чтобы держать в репозитории и исходную историю, и отредактированную

• просмотра веток с помощью qgit (git-cola, gitk — вот он есть часто), на самый крайний случай — git log --graph)

• Редактирование истории

  • Поправить последний коммит: git commit --amend (или --amen ♱)

  • Изменить прошлое: git rebase -i

    • pick, edit, squash

    • продолжение (git rebase --continue) после edit

    • переупорядочение коммитов

Д/З

Для решения задач заводите виртуальные окружения с помощью pipenv в каждом отдельном каталоге с решениями (1, 2 и т п.)

• Задача_1: напишите программу, реализующую простейший multi-user dungeon (по ходу практикума, MUD будет усложняться)

  • имеется поле 10х10 клеток; рисовать поле и его наполнение - не нужно
    • по каждой оси нумерация с 0 по 9
    • первая координата задает координату по горизонтали, вторая - по вертикали
    • клетка (0, 0) находится в левом верхнем углу поля (важно для навигации)
  • в каждой клетке может либо быть пусто, либо находиться один монстр
  • по полю ходит игрок; когда он попадает на клетку с монстром, случается "происшествие" (encounter)
  • в начале игры игрок появляется в клетке (0, 0)
  • настройка поля и игровой процесс организованы при помощи командной строки

  • должен поддерживаться не только интерактивный режим (с консольным вводом), но и режим с получением команд из текстового файла (перенаправление ввода при помощи "<") - это нужно для автотестирования

  • начальная версия командного языка:

    • up, down, left, right

      • перемещение по полю на одну клетку в выбранном направлении

      • если игрок переходит через границу поля, он появляется у противоположной границы (например, left в позиции (0, 5) переводит в позицию (9, 5))

      • при выполнении команды выводится: "Moved to (<x>, <y>)", где <x>, <y> - координаты клетки, куда попал игрок

      • если игрок попал в клетку с монстром, случается "происшествие", логика которого описана ниже

    • addmon <x> <y> <hello>

      • добавление в клетку (x, y) монстра, при встрече говорящего слово-приветствие, заданное в <hello> (достаточно поддерживать слова без пробелов)

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

      • при выполнении команды выводится: "Added monster to (<x>, <y>) saying <hello>"; если монстр заменяется, также выводится, с новой строки, "Replaced the old monster"

    • при вводе неверной команды должно выводиться "Invalid command"
    • при вводе команды с неверными аргументами должно выводиться "Invalid arguments", фанатично проверять корректность аргументов НЕ нужно
  • отработка происшествия (т.е. попадания игрока на клетку с монстром):

    • происшествие должно отрабатываться в функции encounter(x,y), вызываемой после вывода "Moved to ..."

    • вывести текстового монстра, произносящего слово-приветствие

    • для формирования монстра, говорящего текст, используется функция cowsay(text) из модуля python-cowsay

      • этот модуль нужно поставить в окружение с помощью pipenv install

      • для начала все монстры будут выглядеть как default'ная корова из cowsay

• Задача_2: добавьте в MUD (на параллельной ветке в git) поддержку именованных монстров, при этом пользуйтесь редактированием истории на ветке

  • Скопируйте решение Задачи_1.

  • новая функциональность (её нужно разбить на коммиты, как сказано ниже!):

    • поддержка команды addmon <name> <x> <y> <hello> , где <name> это имя монстра (строка без пробелов)

      • старый (без имени) формат команды больше не должен поддерживаться
    • для клетки (x, y) должно запоминаться имя монстра, в дополнение к строке-приветствию

    • строка, выводимая при успешном добавлении монстра, должна выглядеть так: "Added monster <name> to (<x>, <y>) saying <hello>"

    • когда игрок попадает на клетку с монстром, в функции encounter() должно выводиться существо из коллекции модуля python-cowsay, произносящее приветствие (использовать функцию cowsay(message,cow=name))

    • при выполнении команды addmon должно проверяться, что <name> это имя одного из "штатных" существ, доступных в python-cowsay (список имен см. list_cows). Если проверка неуспешна, добавление монстра не выполняется, и выводится "Cannot add unknown monster".

  • занесите новую функциональность на ветку namedmonster (создание ветки: git checkout -b) в виде следующих коммитов, именно в таком порядке:

    • а) доработка разбора и обработки команды addmon <x> <y> <name> <hello>, кроме проверки того, что <name> - имя "штатного" существа

      • порядок аргументов перепутан специально, чтобы потом редактировать историю

    • б) добавление передачи имени монстра в вызов cowsay() из функции encounter()

    • в) добавление в обработку команды addmon проверки того, что <name> - имя "штатного" существа

  • каждый коммит нужно выполнять после отладки соответствующей функциональности, удалив отладочный код; разработали+отладили а) => занесли а), потом переходим к б), и т.п.

  • отредактируйте историю (git rebase -i) на ветке namedmonster:

    • в коммите а) замените в разборе addmon порядок аргументов команды на правильный (опция edit)

    • переставьте местами коммиты б) и в)

    • содержание коммитов в истории удобно контролировать при помощи команды git log --patch

  • ещё раз отредактируйте историю на ветке namedmonster:

    • объедините коммиты а) и в)
  • FIXME: нужен ли merge на основную ветку, и если да, то когда? На занятии про merge?