Python и открытая разработка; использование Git
- (повторение) Свободное лицензирование и Python
- ⇒ Возможность открытой разработки
- Открытая разработка:
- Низкий порог входа-выхода
- Произвольная мотивация
- Динамическая профессиональная иерархия
- Свободное распространение как условие развития
- Распределённая совместная разработка
- Информационное пространство (документация/взаимодействие)
Сообщество Python и разработка
- Сам Python:
2022-02-08: 355,842 projects, 3,215,663 releases, 5,559,317 files, 569,827 users
Несколько сотен несвободных проектов, остальные — свободные
(год назад: 2021-02-10: 288,767 projects, 2,378,715 releases, 3,869,692 files, 484,667 users)
https://readthedocs.org — документация
- (никто не мешает использовать GH или вообще что угодно)
История с pip search (баг, картинка)
pip-search (наверное)
- См. выше про packaging
- Разработка стандартов (egg, wheel)
- Поддержка утилит (pip, setuptools, venv, pipenv)
- …
Использование Git
Система контроля версий:
- Хранение
- Версионирование
- Файлов/объектов
Состояний всего корпуса кода
- История изменений
- Возможно, нелинейная (орграф, точнее — сеть)
Коротко о VCS/DVCS
VCS:
Цикл работы с VCS
Используется «централизованный репозиторий на всех»
- Синхронизация
- Редактирование / отладка
- Оформление коммита
- Публикация
Проблема: совместная работа над одним корпусом текстов
- Интерференция изменений
- В частности взаимоблокировка merge/push
- Изменения опубликованных исходников задним числом
DVCS
Git
- Немного истории
Работа с Git как с локальной VCS
Структура локального хранилища:
Рабочая копия — полные набор набор файлов из проекта
Поначалу этот набор соответствует определённому состоянию проекта (т. н. дереву)
- Модификация рабочей копии ничего не меняет (кроме того, что набор теперь не соответствует ничему)
Хранилище (репозиторий) — подкаталог .git (обычно в каталоге с рабочей копией)
Цикл работы с локальным хранилищем
- Инициализация.
git init
- Изменение рабочей копии — редактирование/удаление/добавление файлов.
- Чтобы посмотреть, чем рабочая копия отличается от соответствующего дерева в репозитории:
git status
- Чтобы посмотреть, чем рабочая копия отличается от соответствующего дерева в репозитории:
- Подготовка коммита — надо пометить файлы, которые в него войдут.
git add список файлов
В действительности добавлять можно даже не файлы, а отдельные изменения в них (см. git add --interactive)
- Можно добавить сразу всё:
git add *
Если сейчас сделать git status, увидим изменения, которые будут добавлены в коммит
- Оформление коммита — создаём на основании изменений рабочей копии новое дерево и обновляем репозиторий
git commit
- В процессе коммита запускается редактор, в котором надо отредактировать коммит-сообщение
Чтобы поменять редактор с vim на что-нибудь иное, надо изменить файл .git/config. Это можно сделать, например, с помощью командной строки git config core.editor 'ваш любимый редактор'
Обратите внимание на то, что git запускает редактор в интерактивном (foreground) режиме, дожидается его завершения, и только потом продолжает работу. Поэтому просто gvim, например, не годится, используйте gvim -f
- При этом в репозитории создаётся три типа объектов
это новое дерево (список всех файлов) — tree
коммит-сообщение — commit
и все изменённые файлы (blob)
переход к п. 1.
Историю коммитов можно посмотреть командой git log. Для того, чтобы отключить постраничный просмотр, используйте git -P log.
Все объекты имеют уникальный ID (это SHA-1 хеш). Объект с ID, допустим, 8dccc7a1d248ea923156b2e762e576b44e07886a, хранятся в файле с именем
.git/objects/8d/ccc7a1d248ea923156b2e762e576b44e07886a
- Посмотреть содержимое объектов можно (но непонятно, зачем ☺), например, так:
python3 -c "import sys; import zlib; print(zlib.decompress(sys.stdin.buffer.read()))" < .git/objects/8d/ccc7a1d248ea923156b2e762e576b44e07886a
Изменения, сделанные только в локальном репозитории, никто, кроме вас не видит. Это значит, что вы спокойно можете редактировать и изменять историю уже сделанных изменений, при условии, что изменяемые вами коммиты нигде не опубликованы.
Например, если вам не понравился последний коммит, и вы хотите в нём что-то поменять — переписать сообщение, поправить изменение в файле и т. п. — можно сделать нужные изменения и выполнить git commit --amend. Тогда новый коммит не добавится в историю, а заменит в ней старый. В него, разумееется, попадёт всё, чем текущая рабочая копия отличается от дерева в предпоследнем.
Д/З
Создать публичный репозиторий (GitHub, GitLab, факультетский GitLab, source.ht, где угодно
Для получения оценки необходимо зарегистрировать его тут
Установить и научиться пользоваться командной строкой git в объёме цикла «add → commit → push → pull → …»
Для windows рекомендуется официальный клиент, в состав которого входит unix-подобная командная строка — для совместимости с лекциями