Публичный репозиторий. Сторонние модули из pypi

Особенность нынешней лекции: публичный репозиторий без рассказа о механизмах публикации.

• Один только SSH требует отдельной лекции

• В действительности от «удалённого» репозитория требуется только поддержка push и pull — а это может быть хоть соседний каталог!

Git: публичный репозиотрий

Цикл разработки:

0. Создание или выбор удалёного репозитория и clone

1. Синхронизация (pull) = fetch + merge
2. Стандартный цикл разработки (следующие три пункта могут повторяться по кругу):
   1. Изменение
   2. Оформление коммита (add и т. п.)
   3. Коммит (commit)
3. Публикация (push)

Перед публикацией стоит убедиться, что и файлы, и сообщения соответствуют принятой дисциплине

Проблема «удалённого init»: нет такой команды при доступе без командной строки.

Ответственная публикация и переписывание локальной истории

• Правила оформления коммитов
  1. Одно изменение = один коммит

     • «Изменение» — это решение какой-то одной задачи (багфикс, новая фича, редизайн и т. п.)

     • Если задача слишком большая, её следует разбить на подзадачи в отдельных коммитах
     • (если ещё больше или одновременно с другими задачами — работа с отдельными ветками, об это позже)
  2. Коммит не ломает уже имеющихся свойств (например, приложение продолжает работать не хуже, чем раньше)
     • Если для восстановления свойств требуется последовательность коммитов, стоит использовать ветки
  3. Формат коммит-сообщения:

     Какая задача решена (одна строка)
     
     Более подробное описание проделанной работы
     в нескольких строках (дисциплина оформления бывает разная)

     • Иногда расписывают про каждый файл/подсистему
     • Иногда указывают класс исправления (исправление, новая фича, обновление, стиль и т. п.)

Перезапись истории: введение

• Исправить последний коммит можно с помощьюgit commit --amend,

  • при этом время коммита сохранится, а его ID и всё, что вы исправили, поменяется

• Более общий метод — git rebase -i начиная_с_какого_коммита`

  • например, git rebase -i HEAD^^^ (или HEAD~3) — это исправление трёх последних коммитов

• Почему переписывать историю плохо?
  • Проблемы совместной разработки (обновления и слияния)

  • даже если изменить только текст коммит сообщения, это будет новый коммит

• Когда можно переписывать историю?

  • Коротко: в диапазоне между HEAD и origin (т. е. всё, что не опубликовано)

Pip

Структура дистрибутива python

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

  • /usr/lib64/Python3.12 — сам Python

  • /usr/lib/Python3/site-packages — сторонние модули, написанные на чистом Python

  • /usr/lib64/Python3/site-packages — сторонние модули с использованием разделяемых библиотек

  • Если Python не принадлежит пакету, и установлен вручную, соответствующие пути берутся из каталога, в который он установлен

• Пользовательские каталоги

  • "."

  • $HOME/.local/lib/python3.12/site-packages (ALT: $HOME/.local/lib/python3/site-packages)

• sys.path

Источник пакетов: PyPI

Как ставить: pip install --user имя

• Зависимости
• Невозможность полного удаления дерева зависимостей)
• Модули на Си и др. языках?
  • «наивная» попытка сборки прямо во время установки
  • относительная ненадёжность бинарных компонентов
  • ⇒ мода на pure python реализации

• бонус: сценарии приезжают в ~/.local/bin (нужно добавить в $PATH)

Проблемы pip install с правами администратора

• Говорят, что установку в $HOME/.local запретят под горячую руку вместе с установкой в систему (см. pipx далее)

Откуда брать pip: python3 -m ensurepip — как раз установится в .local/…

• присутствует не во всех дистрибутивах linux, иногда надо строго ставить соответствующий системный компонент

Работа с venv

• Проблемы системной и локальной пользовательской установок
  • Зоопарк
  • Определение актуальных для проекта зависимостей
  • Разноверсица

  • Невозможность удаления ненужных модулей по отсутствию зависимостей

• модуль venv

  • создание: python3 -m venv каталог

  • . bin/activate для настройки $PATH

  • …

  • Структура каталогов: bin, lib/python3/site-packages и др.

• Никакой «виртуализации». Достаточно запускать python или pip из некоторого отдельного подкаталога, чтобы он не заметил системных модулей. А для этого достаточно поставить этот подкаталог первым в $PATH.

Расширения venv

• virtualenv — практически то же, что и venv

• PipX — pip + автоматически подбираемый venv

• Pipenv — pip + venv + pipfile и обвязка для воспроизводимой сборки

Д/З

На забудьте зарегистрировать свой репозиторий с Д/З.

0. Исследовать стандартный модуль argparse (учебник) и сторонний модуль python-cowsay ( есть несколько аналогичных модулей, нужен именно этот)

1. Создать в репозитории с Д/З подкаталог 02_PushPip (по последнему фрагменту URL данной лекции) и поместить туда решение следующей задачи:

2. Написать программу cow_say.py, которая работает аналогично исходной программе cowsay — запускается из командной строки и принимает такие же параметры.

   • Как минимум должны поддерживаться те ключи исходного cowsay, поведение которых можно задать параметрами функция cowsay.cowsay() из модуля (она уже реализует всю логику, кроме ключа "-l", см документацию по ней)

   • Обрабатывая ключ "-l" нужно вызывать другую функцию — cowsay.list_cows().

   • На надо заботиться о том, чтобы cow_say.py работала в точности так же, как cowsay — например, -h в argparse точно работает по-другому.

   • При написании придерживаться дисциплины «одно изменение (не ломающее работу программы) — один коммит» и аккуратно оформлять коммит-сообщения

   • Предполагается, что модуль python-cowsay уже установлен (например, в ~/.local с помощью pip), его не надо копировать / класть в 02_PushPip и т. п.

3. Опубликуйте результат. Не забывайте о шестидневном (до воскресенья включительно) дедлайне на решения!