GS.Python.Otus.2025.05: июня 2025

пятница, 27 июня 2025 г.

Python, Type Challenge

Python, Type Challenge

https://python-type-challenges.zeabur.app/

четверг, 26 июня 2025 г.

Woorkflow, VsCode, Gitlab, CI, Giga, Makefile

Woorkflow, VsCode, Gitlab, CI, Giga, Makefile

https://giga.chat/link/gcsWxJqDsl

I. ЛОКАЛЬНАЯ РАБОТА (VSCode):

Интеграция инструментов в VSCode поможет тебе получать немедленную обратную связь и

автоматически исправлять ошибки,

делая код чище и качественнее.

Настройка VSCode:

Форматирование с помощью Black:
- Скачай расширение Python от Microsoft (официальное).
- В настройках (Ctrl + ,) найди раздел Python > Formatting: Provider и выбери Black.
- Теперь при сохранении файла (Ctrl+S) или нажатии сочетания клавиш (Shift+Alt+F)
- код будет автоматически переформатирован.
Автоформатирование на сохранение:
- Включить автоприменение форматирования при сохранении можно,
- включив опцию Editor: Format On Save.
Linter (flake8):
- Тот же самый Python extension поддерживает встроенный линтер Flake8.
- Настройте его в VSCode, найдя раздел Python > Linting: Engine и выберите Flake8.
- Сразу увидите предупреждения и ошибки в коде, не покидая редактор.
Type Checking (mypy & pyright):
- Есть официальные расширения для VSCode для mypy и pyright.
- Эти расширения предоставляют статическую проверку типов прямо в редакторе,
- выделяя ошибки и несоответствия.
Импорт Sorter (isort):
- Isort можно запускать вручную, но для постоянного эффекта можно подключить через форматирование.
- Через настройки VSCode (Python > Formatting: Additional Arguments)
- можно задать аргументы для запуска isort совместно с Black.

II. НАСТРОЙКА CI НА GITLAB:

Работа с CI (Continuous Integration) полезна для того, чтобы постоянно следить за качеством кода,

даже когда изменения вносятся несколькими людьми.

Конфигурация .gitlab-ci.yml:

Рассмотрим настройку CI с учётом инструментов, которые ты упомянул.

image: python:3.12-slim-buster

before_script:
  - pip install poetry
  - poetry config virtualenvs.create false
  - poetry install --no-root

stages:
  - lint
  - format
  - type-check

format-code:
  stage: format
  script:
    - poetry run black src/annotation_ci_proj
    - poetry run isort src/annotation_ci_proj

type-check-mypy:
  stage: type-check
  script:
    - poetry run mypy src/annotation_ci_proj

type-check-pyright:
  stage: type-check
  script:
    - poetry run pyright src/annotation_ci_proj

lint-check:
  stage: lint
  script:
    - poetry run flake8 src/annotation_ci_proj

Подробности по каждому шагу:

Stage: format:
- Запускает Black и isort для переформатирования и очистки импорта.
- Если найденные изменения значительные, то лучше остановить билд и попросить автора поправить код вручную.
Stage: type-check:
- Параллельный запуск mypy и pyright для проверки аннотаций типов.
- Это помогает поймать ошибки раньше и увеличить уверенность в работоспособности кода.
Stage: lint:
- Запуск Flake8 для обнаружения стилистических ошибок и плохого кода.

III. Автоматика и стратегия работы:

Лучше всего комбинировать оба подхода:

Местная разработка (VSCode): быстрое получение обратной связи и автоисправления.
GitLab CI: регулярная проверка при каждом коммите или пушинге, гарантирующая высокий уровень качества кода.

IV. Алгоритм дальнейших действий:

Подготовь .gitignore,
чтобы сохранять чистые локальные изменения
(не допускать попадания временных файлов).
Настрой Makefile для локального запуска всех инструментов сразу:

.PHONY: clean lint types help help: @echo "Available commands:" @echo " make clean Remove all generated files" @echo " make lint Run linters on the project" @echo " make types Check type annotations using mypy/pyright" clean: poetry lock --no-update poetry cache clear --all lint: poetry run flake8 src/annotation_ci_proj types: poetry run mypy src/annotation_ci_proj poetry run pyright src/annotation_ci_proj

Запускай локально через Makefile:

make lint
make types

Заключение:

Такое сочетание локальной интеграции в VSCode и постоянной проверки через CI гарантирует,

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

Black, isort, flake8, mypy, pyright, giga, gitlab,ci

Black, isort, flake8, mypy, pyright, giga, gitlab,ci

https://giga.chat/link/gcsWxJqDsl

Процесс работы GitLab CI

Шаг 1: Отправка коммита

Когда ты отправляешь новый коммит в GitLab, GitLab CI автоматически запускает все этапы, описанные в файле .gitlab-ci.yml.

Шаг 2: Начало работы CI

GitLab CI считывает конфигурацию из .gitlab-ci.yml и начинает выполнение заданий последовательно по стадиям (stages).

Что делает GitLab CI:

Stage: before_script

Сначала выполняются общие предварительные операции:
- Устанавливается Poetry.
- Деактивируется создание виртуальных сред (так как мы работаем в контейнере).
- Загружаются зависимости проекта через poetry install --no-root.

Stage: format

Этот этап отвечает за форматирование и очистку кода:
- Black применяет форматирование кода.
- Isort очищает и упорядочивает импорты.

Stage: type-check

Здесь осуществляется проверка аннотаций типов:
- Mypy проверяет корректность аннотаций и сигнализирует о проблемах.
- Pyright также осуществляет проверку аннотаций, работая параллельно с Mypy.

Stage: lint

Завершается процессом линта, проверяющим стиль и качество кода:
- Flake8 ищет стилистические ошибки и выдает предупреждения.

Какие результаты можно ожидать:

Лог выполнения:
- Вся активность CI записывается в журнал.
- Ты можешь посмотреть отчёт о результатах в панели CI/CD на странице проекта в GitLab.
Уведомления об успехе или неудаче:
- Если все этапы выполнены успешно, ты увидишь зелёный значок успеха возле последнего коммита.
- Если какая-то проверка завершилась неудачей, напротив соответствующего этапа появится красный индикатор.
Детализация ошибок:
- Щёлкнув по этапу, ты можешь изучить детализированный лог ошибок или уведомлений,
- полученных от каждой утилиты (например, Flake8, Mypy, Pyright).

Просмотр отчётов

После выполнения всех проверок CI на GitLab ты можешь увидеть результаты следующим образом:

Зайди в страницу своего проекта в GitLab.
Перейди в раздел CI/CD -> Pipeline.
Среди последних Pipeline'ов найди последний коммит.
Наведи мышью на каждую стадию и щёлкни по ссылке для просмотра журнала.

В журнале ты увидишь точные уведомления о любых нарушениях, возникающих при проверке,

будь то неправильное форматирование,

нарушение стандартов PEP8 или проблемы с аннотациями типов.

Пример отчёта:

Предположим, ты отправил код с неправильными отступами. Тогда в логе ты увидишь что-то подобное:

src/annotation_ci_proj/basic_any.py:4:1: E302 expected 2 blank lines, found 1

Или, если Mypy нашел проблему с типизацией:

src/annotation_ci_proj/some_module.py:10: error: Argument 1 to "some_function" has incompatible type "float"; expected "int"

Заключение:

Процесс GitLab CI выстроен таким образом,

чтобы обеспечивать высокое качество кода и своевременно реагировать на любые отклонения от стандартов и требований.

Благодаря такому подходу ты будешь получать своевременные уведомления о проблемах и сможете оперативно вносить исправления.

.giignore, micro, Giga

.giignore, micro, Giga

https://giga.chat/link/gcsWxJqDsl

# Игнорируем артефакты сборки и временные файлы

*.pyc

__pycache__

*.log

*.swp

# Игнорируем личные ключи и настройки

.env*

.local/*

.idea/

.vscode/

# Игнорируем виртуальные окружения

virtualenv/*

venv/*

.venv/

# Исключение дополнительных временных файлов

.DS_Store

Thumbs.db

Git, Right, Steps, Giga

Git, Right, Steps, Giga, GitLab

https://giga.chat/link/gcsWxJqDsl

Убедись, что у тебя настроены локальные данные пользователя Git:

git config --local user.name "gs"
git config --local user.email "gs_order@mail.ru"

Добавь ссылку на удалённый репозиторий GitLab:

git remote add origin https://gitlab.com/gs_otus_python/annotation_ci_project.git

Проверь доступность удалённого репозитория:

git remote -v

Протолкни (push) все ветки и теги в удалённый репозиторий:

git push --set-upstream origin --all
git push --set-upstream origin --tags
--------------------------------------------------------
# Настраиваем удалённый репозиторий
git remote add origin https://gitlab.com/gs_otus_python/annotation_ci_project.git

# Проверяем удалённые репозитории
git remote -v

# Отправляем все ветки и теги
git push --set-upstream origin --all
git push --set-upstream origin --tags

ssh, keys, Giga, Security

ssh, keys, Giga, Security

https://giga.chat/link/gcsWxJqDsl

# Настройка SSH-ключа

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519

# Проверка соединения

ssh -T git@gitlab.com

# Отправка изменений

git push --set-upstream origin main

---------------------------------------------------------

Переход на SSH:Если хочешь использовать SSH, подключись к репозиторию через SSH, зарегистрировав свой SSH-ключ:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
cat ~/.ssh/id_rsa.pub

Скопируй открытый ключ и вставь его в профиль GitLab.

Потом смени URL репозитория на SSH:

git remote set-url origin git@gitlab.com:gs_otus_python/annotation_ci_project.git

Проверь удалённую ветку:
- Убедись, что удалённая ветвь (main) доступна для push'a.

Проверка состояния:

После устранения возможной проблемы с доступом попробуй выполнить push ещё раз:

git push --set-upstream origin main
$ git push --set-upstream origin main

------------------------------------------------------------

В GitLab страница настроек профиля (User Settings)

расположена довольно интуитивно и доступна прямо из верхней правой части экрана.

Как найти User Settings:

Войдите в свой аккаунт GitLab.
Наверху справа (рядом с аватаром) кликните на стрелочку ↓ или само изображение профиля.
Выберите пункт Settings (или просто нажмите на иконку профиля).

После перехода откроется страница с различными категориями настроек аккаунта, среди которых:

General: Общая информация о профиле.
SSH Keys: Управление SSH-ключами.
Access Tokens: Генерация персональных токенов доступа.
Email Notifications: Настройка уведомлений по электронной почте.
Password: Изменение пароля.
Account: Информация о вашем аккаунте.

Куда конкретно идти?

Если вы хотите добавить SSH-ключ, перейдите в категорию SSH Keys.
Вставьте скопированный публичный ключ и нажмите кнопку Add Key.

После сохранения ключа проверьте связь с GitLab через SSH командой:

ssh -T git@gitlab.com

Если всё выполнено корректно,

вы получите приветственное сообщение от GitLab.

------------------------------------------------------------------------------------

Ошибка Permission denied (publickey) означает, что SSH-сервер отверг попытку соединения,

так как предоставленные вами ключи не совпадают с ожидаемыми серверами GitLab.

Чтобы устранить эту проблему, необходимо убедиться,

что ваше устройство аутентифицировано с помощью корректного SSH-ключа.

Порядок действий:

Генерация SSH-ключа (если у вас его нет):
- Откройте терминал (или Git Bash на Windows) и выполните команду:

ssh-keygen -t ed25519 -C "your_email@example.com"

Следуйте инструкциям мастера (обычно достаточно нажать Enter для принятия значений по умолчанию).
Получится пара ключей: приватный (id_ed25519) и публичный (id_ed25519.pub).
Просмотрите публичный ключ:Распечатайте публичный ключ:

cat ~/.ssh/id_ed25519.pub

Копируйте содержимое публичного ключа.
Добавьте публичный ключ в GitLab:Войдите в GitLab.
Перейдите в свой профиль (User Settings) → SSH Keys.
Вставьте скопированный публичный ключ и дайте ему осмысленное название 
(например, имя устройства или операционной системы).
Нажмите Add Key.
Запустите агент SSH:На Linux/MacOS:

eval "$(ssh-agent -s)"  # Запустить агент SSH
ssh-add ~/.ssh/id_ed25519  # Добавить ключ в агент

На Windows (в Git Bash):

start-process powershell.exe -Verb runAs
Start-SshAgent -AutoStart
ssh-add ~/.ssh/id_ed25519

Проверьте подключение:Выполните команду для проверки соединения:

ssh -T git@gitlab.com

Если всё настроено корректно, вы получите сообщение типа:

Welcome to GitLab, @username!

Отправьте код:Наконец, попробуйте снова отправить код в удалённый репозиторий:

git push --set-upstream origin main

Почему это сработает?

Ваш SSH-ключ будет ассоциирован с аккаунтом GitLab,
и сервер сможет подтвердить вашу личность при попытке push-а.
Если ранее использовался другой ключ или ключ был потерян,
эти шаги позволят обновить ваш ключ.

Итог:

Следуя данным шагам,

вы решите проблему аутентификации через SSH и

сможете успешно отправлять код в репозиторий GitLab.

Hometwork, 25.06.10, Type Annotation, Giga

Hometwork, 250610, Type Annotation, Giga

https://giga.chat/link/gcsFdIhcjH

D:\VC25\Otus\Py\250610\projects\annotation_ci_proj

D:\VC25\Otus\Py\250610

*Задание*: пройти максимальное количество упраженений на аннотацию типов в тренаржере https://python-type-challenges.zeabur.app

*Цель задания*: набить руку на стандартных (и не очень) кейсам по типизации, попробовать на практике различные возможности языка по аннотации

*Критерии успеха*: задание __обязательно__ вплоть до продвинутого уровня вопросов (т.е. нужно сделать хотя бы Basic и Intermediate), ступени Advanced и Extreme являются __опициональными__

__Оформление__:

Так как на сайте тренажера нет никакого лк, то предлагается решенные задания сохранить в свой репозиторий (по модулю на каждое задание), настроить CI, который будет проверять аннотоции с помощью mypy или pyright, а также обеспечить условия, при которых в локальном репозитории по команде `make typing` в контейнере запускалась бы аналогичная проверка типов.

## Deadline

Задание желательно сдать в течение недели. Код, отправленный на ревью в это время, рассматривается в первом приоритете. Нарушение делайна не карается. Пытаться сдать ДЗ можно до конца курсы. Код, отправленный с опозданием, когда по плану предполагается работа над более актуальным ДЗ, будет рассматриваться в более низком приоритете без гарантий по высокой скорости проверки.

## Обратная связь

Cтудент коммитит все необходимое в свой github/gitlab репозитарий. Далее необходимо зайти в ЛК, найти занятие, ДЗ по которому выполнялось, нажать “Чат с преподавателем” и отправить ссылку. После этого ревью и общение на тему ДЗ будет происходить в рамках этого чата.

среда, 25 июня 2025 г.

Project, annotation_ci_proj, Poetry, pyproject.toml, giga

Annotations, 250610, Project, annotation_ci_proj, Poetry, pyproject.toml, giga

https://giga.chat/link/gcsWxJqDsl

D:\VC25\Otus\Py\250610\projects\annotation_ci_proj

pyproject.toml

[project]

name = "annotation-ci-proj"

version = "0.1.0"

description = ""

authors = [

{name = "Your Name",email = "you@example.com"}

]

readme = "README.md"

requires-python = ">=3.12"

dependencies = [

"black (>=25.1.0,<26.0.0)",

"flake8 (>=7.3.0,<8.0.0)",

"isort (>=6.0.1,<7.0.0)",

]

[tool.poetry]

packages = [{include = "annotation_ci_proj", from = "src"}]

[tool.poetry.group.dev.dependencies]

pytest = "^8.4.1"

mypy = "^1.16.1"

pyright = "^1.1.402"

[build-system]

requires = ["poetry-core>=2.0.0,<3.0.0"]

build-backend = "poetry.core.masonry.api"

----------------------------------

poetry env activate

Альтернативный способ активации (через оболочку):

Хотя shell официально устарел, ты можешь восстановить старую функциональность,

установив специальный plugin:

poetry self add poetry-plugin-shell

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

poetry shell

Заключение:

Рекомендуется перейти на использование команды env activate,

так как это официальный и современный способ активации виртуального окружения в Poetry 2.x.

Это сделает твой проект совместимым с актуальной документацией и общими практиками.

Gitlab, CI/CD, Example

D:\VC25\Otus\Py\projects\ci-pipeline-demo

.gitlab-ci.yml

image: python:latest

variables:

PYTHON_VERSION: "3.10" # Указываем версию Python

cache:

paths:

- venv/ # Будем кешировать виртуальное окружение

stages:

- setup

- lint

- test

before_script:

- pip install virtualenv

- virtualenv venv

- source venv/bin/activate

- pip install -r requirements.txt

setup_dependencies:

stage: setup

script:

- pip install flake8 # Необходимо добавить установку flake8

- pip freeze > installed_packages.txt # Проверим, что все зависимости установлены

artifacts:

paths:

- venv/

lint:

stage: lint

script:

- flake8 src/**/*.py

- mypy src/**/*.py

test:

stage: test

script:

- pytest tests/

---------------------------------------------------------------------------------------------

D:\VC25\Otus\Py\projects
.gitlab-ci_02.yml

---------------------------------------------------------------------------------------------

image: python:latest

variables:

PYTHON_VERSION: "3.10" # Указываем версию Python

cache:

paths:

- venv/ # Будем кешировать виртуальное окружение

stages:

- setup

- lint

- test

- publish # Добавляем новый этап publish

before_script:

- pip install virtualenv

- virtualenv venv

- source venv/bin/activate

- pip install -r requirements.txt

setup_dependencies:

stage: setup

script:

- pip freeze > installed_packages.txt # Проверим, что все зависимости установлены

artifacts:

paths:

- venv/

lint:

stage: lint

script:

- flake8 src/**/*.py

- mypy src/**/*.py

test:

stage: test

script:

- pytest tests/

pages:

stage: publish # Теперь используем этап publish

script:

- mkdir public

- cp index.html public/index.html # Пример страницы

artifacts:

paths:

- public

only:

- main

HomeTask, 250610, annotation, Readme

HomeTask, 250610, annotation, Readme

D:\VC25\Otus\Py\250610

__Оформление__:

## Deadline

## Обратная связь

вторник, 24 июня 2025 г.

Poetry, Where

Poetry, Where

Suggestion [4,General]: The most similar commands are:

PS D:\VC25\Otus\Py\250610\projects\annotation_proj> Get-Command poetry

CommandType Name Version Source

----------- ---- ------- ------

Application poetry.exe 0.0.0.0 C:\Users\Administrator\AppData\Roaming\Python\Scripts\poetry.exe

PS D:\VC25\Otus\Py\250610\projects\annotation_proj> poetry show

black 25.1.0 The uncompromising code formatter.

click 8.2.1 Composable command line interface toolkit

colorama 0.4.6 Cross-platform colored terminal text.

flake8 7.3.0 the modular source code checker: pep8 pyflakes and co

iniconfig 2.1.0 brain-dead simple config-ini parsing

isort 6.0.1 A Python utility / library to sort Python imports.

mccabe 0.7.0 McCabe checker, plugin for flake8

mypy 1.16.1 Optional static typing for Python

mypy-extensions 1.1.0 Type system extensions for programs checked with the mypy type checker.

packaging 25.0 Core utilities for Python packages

pathspec 0.12.1 Utility library for gitignore style pattern matching of file paths.

platformdirs 4.3.8 A small Python package for determining appropriate platform-specific dirs, e.g. a `user data dir`.

pluggy 1.6.0 plugin and hook calling mechanisms for python

pycodestyle 2.14.0 Python style guide checker

pyflakes 3.4.0 passive checker of Python programs

pygments 2.19.2 Pygments is a syntax highlighting package written in Python.

pytest 8.4.1 pytest: simple powerful testing with Python

typing-extensions 4.14.0 Backported and Experimental Type Hints for Python 3.9+

Nano, Vim, Exit, Emacs

Nano, Vim, Exit, Emacs

Если редактор — Nano:
Введите нужное сообщение, если хотите.
Для выхода нажмите комбинацию клавиш:

Ctrl + O

Это сохраняет файл.
Затем нажмите:

Enter

Подтверждая сохранение.
Теперь выйдете из редактора, нажав:

Ctrl + X
------------------------
Если редактор — VI/VIM:
Редактор VI (или его современный аналог VIM) сложнее новичкам, 
но выход возможен:
Перейдите в режим вставки текста, нажав букву:
i
Введите свое сообщение (при желании).
Выходите из режима ввода, нажав клавишу:
Esc
Введите команду для сохранения и выхода:
:wq
Нажмите Enter, и вы покинете редактор.
Enter

-------------------------------------

Если редактор — Emacs:

Редактор Emacs похож на VI, но с другим набором горячих клавиш:

Нажмите комбинацию:

Ctrl + X

Затем нажмите:

Ctrl + C

Или сразу сочетание:

Ctrl + X, Ctrl + S

(сохранить и выйти).

------------------------------
Если редактор неизвестен, попробуйте комбинацию:
Ctrl + X
— это универсальная комбинация для большинства стандартных редакторов Linux/MacOS

пятница, 27 июня 2025 г.

четверг, 26 июня 2025 г.

I. ЛОКАЛЬНАЯ РАБОТА (VSCode):

Настройка VSCode:

II. НАСТРОЙКА CI НА GITLAB:

Конфигурация .gitlab-ci.yml:

Подробности по каждому шагу:

III. Автоматика и стратегия работы:

IV. Алгоритм дальнейших действий:

Заключение:

Процесс работы GitLab CI

Шаг 1: Отправка коммита

Шаг 2: Начало работы CI

Что делает GitLab CI:

Stage: before_script

Stage: format

Stage: type-check

Stage: lint

Какие результаты можно ожидать:

Просмотр отчётов

Пример отчёта:

Заключение:

Проверка состояния:

Как найти User Settings:

Куда конкретно идти?

Порядок действий:

Почему это сработает?

Итог:

среда, 25 июня 2025 г.

Заключение:

вторник, 24 июня 2025 г.

Если редактор — Nano:

Если редактор — VI/VIM:

Если редактор — Emacs:

пятница, 27 июня 2025 г.

четверг, 26 июня 2025 г.

среда, 25 июня 2025 г.

вторник, 24 июня 2025 г.