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-подобная командная строка — для совместимости с лекциями 
 
