Python и открытая разработка; использование Git

• (повторение) Свободное лицензирование и Python

  • Свободное лицензирование

  • PSF

  • ⇒ Возможность открытой разработки
• Открытая разработка:
  • Низкий порог входа-выхода
  • Произвольная мотивация
  • Динамическая профессиональная иерархия
  • Свободное распространение как условие развития
  • Распределённая совместная разработка
  • Информационное пространство (документация/взаимодействие)

Сообщество Python и разработка

• Сам Python:

  • PEP-ы

    • Примеры: (разные), pep-635 и его товарищи

    • Гвидо

    • pep-0572 — формальная причина «выхода на пенсию» (письмо)

    • ⇒ комитет по принятию

• Python Package Index

  • 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)

  • Python Packaging User Guide

  • https://readthedocs.org — документация

  • (никто не мешает использовать GH или вообще что угодно)

  • История с pip search (баг, картинка)

    • pip-search (наверное)

• Python Packaging Authority

  • См. выше про packaging
  • Разработка стандартов (egg, wheel)
  • Поддержка утилит (pip, setuptools, venv, pipenv)
  • …

Использование Git

Система контроля версий:

• Хранение
• Версионирование
  • Файлов/объектов

  • Состояний всего корпуса кода

• История изменений
  • Возможно, нелинейная (орграф, точнее — сеть)
• Создание информационного пространства вокруг исходного текста

Коротко о VCS/DVCS

VCS:

• rcs

• CVS

• Subversion

• Fossil, чёрт в ступе

Цикл работы с VCS

Используется «централизованный репозиторий на всех»

1. Синхронизация
2. Редактирование / отладка
3. Оформление коммита
4. Публикация

Проблема: совместная работа над одним корпусом текстов

• Интерференция изменений
  • В частности взаимоблокировка merge/push
• Изменения опубликованных исходников задним числом

DVCS

• Darcs

• Mercurial, Bazaar

• bitkeeper, Git

Git

• Немного истории

• Учебник и документация

Работа с Git как с локальной VCS

Структура локального хранилища:

• Рабочая копия — полные набор набор файлов из проекта

  • Поначалу этот набор соответствует определённому состоянию проекта (т. н. дереву)

  • Модификация рабочей копии ничего не меняет (кроме того, что набор теперь не соответствует ничему)

• Хранилище (репозиторий) — подкаталог .git (обычно в каталоге с рабочей копией)

Цикл работы с локальным хранилищем

0. Инициализация.

   • git init

1. Изменение рабочей копии — редактирование/удаление/добавление файлов.
   • Чтобы посмотреть, чем рабочая копия отличается от соответствующего дерева в репозитории:

     git status

2. Подготовка коммита — надо пометить файлы, которые в него войдут.

   • git add список файлов

   • В действительности добавлять можно даже не файлы, а отдельные изменения в них (см. git add --interactive)

   • Можно добавить сразу всё:

     git add *

   • Если сейчас сделать git status, увидим изменения, которые будут добавлены в коммит

3. Оформление коммита — создаём на основании изменений рабочей копии новое дерево и обновляем репозиторий

   • git commit

   • В процессе коммита запускается редактор, в котором надо отредактировать коммит-сообщение

     • Чтобы поменять редактор с vim на что-нибудь иное, надо изменить файл .git/config. Это можно сделать, например, с помощью командной строки git config core.editor 'ваш любимый редактор'

     • Обратите внимание на то, что git запускает редактор в интерактивном (foreground) режиме, дожидается его завершения, и только потом продолжает работу. Поэтому просто gvim, например, не годится, используйте gvim -f

   • При этом в репозитории создаётся три типа объектов

     1. это новое дерево (список всех файлов) — tree

     2. коммит-сообщение — commit

     3. и все изменённые файлы (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, sr.ht, где угодно

• Для получения оценки необходимо зарегистрировать его тут

• Установить и научиться пользоваться командной строкой git в объёме цикла «add → commit → push → pull → …»

  • Для windows рекомендуется официальный клиент, в состав которого входит unix-подобная командная строка — для совместимости с лекциями