Как AWS у опенсорсера пакеты отжимал

Нерегулярная рубрика "посмотрите, что творится!". Данная история была в оригинале рассказана Кареном в нашем чате (там регулярно происходит интересное), публикую в своем канале с его разрешения.

Новый SDK для AWS от Карена (автора zapros, автора httpx-aiohttp, топ-3 контрибьютора httpx): https://github.com/kap-sh/capo

Как-то я решил написать нормальный SDK для AWS. Их текущий SDK — boto3 — это суперлегаси с кучей костылей: без нормальной типизации, без поддержки асинхронности, почему-то с PascalCase и ещё кучей странных решений.

У меня уже был хороший опыт работы с SDK: до этого я работал над SDK для OpenAI и Anthropic на Python и TypeScript, так что успел накопить некоторое понимание того, как делать SDK хорошо.

С AWS всё немного сложнее: у них около 450 сервисов и примерно 17 миллионов строк сгенерированного кода. Конечно, я не собирался писать всё это вручную. Вместо этого я пишу кодогенератор, который генерирует SDK из спецификаций Smithy (язык и тулинг для спецификаций). Примерно такой же подход я использовал, работая над SDK для OpenAI и Anthropic.

И, конечно, я не стал делать это одним пакетом на PyPI. Прикиньте, устанавливать 17 миллионов строк кода только для того, чтобы создать S3-бакет.

Поэтому я делаю отдельный пакет для каждого сервиса.

Для всех пакетов я выбрал префикс aws-sdk: aws-sdk-s3, aws-sdk-ecs и так далее. Успешно опубликовал около 60 сервисов на PyPI.

А на следующий день до меня достучались ребята из AWS.
Они заметили мою работу, пореспектовали, но сказали, что именно эти имена они сами давно хотели использовать для своего нового SDK — замены boto3. И попросили вернуть им эти имена.

И тут есть ещё одно интересное совпадение: в тот же день PyPI заморозил мой аккаунт. В заморозке он продержался больше месяца. Причины мне так и не объяснили, но, думаю, каждый может сделать свои выводы 🙂

Я не стал с ними бороться и согласился вернуть имена.

Что интересно в данном контексте?

1. Существует PEP, который определяет разрешение конфликтов в пакетах: https://peps.python.org/pep-0541 Там есть пункт о том, что если пакет "нарушает торговую марку", то он может быть отозван как "некорректный". Но там есть важная оговорка, что "честное использование" (например для создания SDK) - разрешено
2. AWS являются спонсорами PyPI: https://aws.amazon.com/ru/blogs/opensource/securing-pypi-for-the-future

Кстати, история про left-pad начиналась так же.

Техническая часть

Что удивительно, так то, что сами AWS не могу сделать нормальный SDK для питона. А один человек в опенсорсе - может. Сделать и синхронную, и асинхронные версии - довольно сложно. Вот так оно выглядит у capo:

from capo_s3 import AsyncS3Client

async def main():
    async with AsyncS3Client() as s3:
        response = await s3.create_bucket("capo")
        print(response)

и

from capo_s3 import S3Client

with S3Client() as s3:
    response = s3.create_bucket("capo")
    print(response)

Внутри, конечно же, zapros, как HTTP фреймворк для запросов.

Что прикольно: все модели данных построены на TypedDict, все ответы типизированы, но с 0 дополнительных кастов. Но типизация все еще помогает понять, какие ответы от каких сервисов можно использовать как входные данные для других, а где - так сделать будет нельзя.

Развязка

Карену поступило предложение работы в AWS с релокацией в США (да, после опенсорс проекта), он отказался по личным причинам.
Они созвонились с разработчиками оттуда, выразили друг другу уважение (как капо и делают 🌚), обсудили технические решения.

Кажется, никто не остался в обиде.
Хорошо, что история хорошо закончилась: у нас есть и контент для канала, и новая библиотека, и счастливый финал.

Обсуждение: Как вы думаете, что на самом деле там произошло? Почему аккаунт заморозили? Как вы думаете, найм через такой опенсорс - реальность или супер-редкая уникальная история? Насколько сильно вы страдали от boto3?

| Поддержать | YouTube | GitHub | Чат |

JIT могут удалить из CPython!

PEP-836: https://peps.python.org/pep-0836

JIT в CPython имеет очень много проблем, давайте их обсудим.

Если вы все пропустили, то вот вам краткий таймлайн всей истории:
- В мае 2021 года создается команда Faster CPython, под руководством Гвидо в MS, которая должна работать над улучшением скорости CPython
- Где-то в 2022м году к команде присоединяется Brandt Butcher, автор первой версии JIT
- В октябре 2023 года, Brandt презентовал свою идею добавления JIT в CPython
- В январе 2024 года, PR был влит в 3.13, создана первая версия Copy-and-Patch JIT
- В апреле 2024 года релиз менеджеры и SC с таких новостей немного прифигели и попросили сделать PEP хотя бы пост-фактум: https://peps.python.org/pep-0744
- В октябре 2024 года выходит 3.13 с JITом, который можно включить опционально
- В мае 2025 года MS увольняет всех участников команды Faster CPython
- В октябре 2025 года выходит 3.14 с JIT бинарниками. Теперь можно было выбрать образ, который планируешь использовать. Free-Threading все еще не поддерживается
- В конце 2025 года добавлен Tracing JIT
- В июне 2026 года SC выпускает объявление, что работа над JIT полностью заморожена до момента пока: не будет опубликован четкий план развития JIT, конкретные метрики успешности проекта, дизайн АПИ (планировали подключать разные JITы в будущем, но от такой идеи отказались)
- В июле 2026 появляется PEP-836 с ответами на вопросы SC, пока его статус "ждет ответа от SC"

Что произойдет, если SC откажется от текущего PEP? Весь код JIT должен быть удален из 3.16+
Возможно ли такое? Вероятность мала, но она пока есть.

А что по скорости?

Перформанс - основная проблема текущего JITа. А точнее отсутствие перформанса.
Официальные цифры такие:

- В 3.13 разница была +-0%, потому что задача была по сути просто добавить инфру для дальнейших оптимизацией. Принимается.
- В 3.14 разброс был от -10% до +20% на разных кейсах. Говорить, что стало быстрее в общем - нельзя, потому надо замерять каждый кусок кода отдельно.
- В 3.15 наконец-то появилась заявленная цель в 5% среднего ускорения. Чего вроде бы добились на всех платформах. Где-то чуть лучше, где-то похуже. Но и кейсы ускорились не все.
- В 3.16 сейчас ставят цель в 10%, пока рано говорить об успешности

Все точные данные можно посмотреть на официальном сайте: https://www.doesjitgobrrr.com

Какие еще большие задачи ждут JIT?

- Необходимо добавить полную поддержку Free-Threading
- Увеличить покрытие тестами
- Добавить поддержку дебаггеров и профайлеров для JIT кода

Цели выше ставились для 3.15, их успешно продолбали. В том числе из-за необходимости писать PEP.

- Добавить 2х человек в команду
- Поддержать LLVM 22 и возможно другие версии
- Полноценная документация
- Возможно получится убрать build-time зависимость от LLVM для сборки JIT, как планировалось ранее

В работе прямо сейчас в рамках 3.16 релиза.

Итоги

Денег больше нет, команда работает на волонтерских началах, сроки жмут, начальство душит. Знакомо? 🌚
Но вера все еще живет!

Я приглашаю вас всех присоединяться к развитию JIT! Давайте вместе сделаем CPython быстрее.
Как? Открывайте задачки, читайте код, реализуйте оптимизации, улучшайте существующие, добавляйте thread-safety для FT, гоняйте бенчмарки, пишите тесты! Работы - буквально вагон.

Обсуждение: Верите ли вы в JIT в CPython? Готовы ли вы помочь?

Одной строкой

- В среду будет митап MoscowPython, где я буду выступать, приходите. Места для регистраций еще есть!
- Релизнули подкаст с @pylounge, поговорили про DMR, псиопы в разработке, общее ощущение усталости и упадка в мировом IT

| Поддержать | YouTube | GitHub | Чат |

Большая бесплатная конференция в Нижнем Новгороде 17 октября

Регистрация: https://itgorky.ru/bolshaya-vstrecha
При поддержке @it52info

Мы продолжаем нашу традицию делать большую осеннюю конференцию в Нижнем.
Вот тут можно почитать / посмотреть как было в прошлом году: https://t.me/opensource_findings/934

Что будет?
- Много разных секций: Python / DevRel / Frontend / Mobille
- Слет всего нашего сообщества @pytho_nn: приедет весь наш опенсорс чат, будет кучу людей из Москвы, Казани, других городов
- Много дружеского и профессионального общения
- Настолки!
- Встреча подписчиков. Приедет много людей из телевизора, всех их мы заманим в бар после конференции, с ними можно будет поговорить, выпить пива, сфотаться, подружиться :)
- Бар, кальяны и тусовка до утра (самое главное, очевидно)

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

Доклады

- 11:00 Иван Кирпичников, опенсорс разработчик Adaptix. Опыт в проде и какие приколюхи можно творить Посмотрим на конкурента Pydantic от нашего сообщества. Посмотрим: где и когда не стоит использовать Pydantic, какие у него актуальные проблемы. Поговорим, за счет чего Adaptix насколько быстрый, как он устроен. И какие уникальные фичи у него есть.
- 12:00 Егор Бугаенко, Huawei, @yegor256news, https://youtube.com/@yegor256 Типичные ошибки начинающего опенсорс разработчика Проанализирую свой опыт работы с сотнями разработчиков в десятках опенсорс проектах, укажу на их ошибки, предложу альтернативы.
- 13:00 Алексей Гладких, Arenadata, @gaxeliy_tdd, https://twitch.tv/gaxeliy Зачем программисту Twitch (что?) Расскажу про недооценённую платформу для коммуникации, выстраивания горизонтальных связей и создания личного бренда. Покажу как можно стримить с технической стороны.
- 14:00 Александр Кондратьев, Ростелеком Modern Tests для Modern REST: современный подход к тестированию Django Modern REST Тесты API могут проверять разные уровни системы: логику контроллера, обработку HTTP-запроса, взаимодействие компонентов и соответствие реализации заявленному контракту. Если не разделять эти задачи, тесты становятся медленными и хрупкими, а высокое покрытие кода не гарантирует корректную работу API. На докладе поговорим о нашем опыте использования django-modern-rest в проде и организации тестов вокруг него: какие уровни проверок мы используем, что тестируем в запросах и ответах и какие инструменты помогают сократить рутинный код. Отдельно рассмотрим роль точной семантической схемы API: как на её основе генерировать тестовые сценарии, проверять реальные ответы и оценивать покрытие операций, параметров и вариантов ответа, а не только строк кода.
- 15:00 Максим Мельников, @pylounge, https://youtube.com/@pylounge Я в СКРЫТОМ ПУЛЕ: выстраиваем процессы в команде без тильта Работа в IT-команде иногда подозрительно напоминает Dota 2: кто-то фармит, кто-то руинит, кто-то молчит до 40-й минуты, а тимлид начинает думать, что снова играет 1 vs 9. Только вместо Рошана - прод, вместо 0/10 мидера - соседняя CRM-команда, а вместо "gg ez" - очередной аварийный комитет. На докладе поговорим о том, как перестать играть в такой режим и начать выстраивать систему: почему токсичность и дизмораль только мешают, зачем учить людей говорить ртом и управлять ожиданиями, почему процессы не должны держаться на одном "рокстар-игроке" и как не превращать каждый фейл в поиск того, кто заруинил. Разберём, как продавать изменения команде, договариваться с бизнесом и другими командами, фиксировать договорённости и автоматизировать правила - чтобы вместо вечного 1 vs 9 получилась команда, которая действительно играет на победу как для бизнеса, так и технического развития проекта.
- 16:00 Хоренян Сурен, Яндекс Реклама, @Khorenyan, https://youtube.com/@SurenKhorenyan Агент пишет код. Я всё ещё программирую У кого-то ИИ забрал удовольствие от программирования; для меня это второе дыхание. Я смотрю на то, что пишет агент, а в голове только одна мысль: "я сделаю лучше". Разберём архитектурные странности в Python-коде от агентов: что можно упростить, переделать или с удовольствием удалить. Для разработчиков, которые пишут с агентами, ревьюят код от агентов и хотят понимать, что вообще происходит с кодовой базой.

А еще будут и другие треки по другим направлениям, их анонсы будут в их сообщества Нижнего и на @it52info.
Нужна только регистрация: https://itgorky.ru/bolshaya-vstrecha

Приходите! Приезжайте! Буду рад всех видеть лично. Хорошо и интересно проведем время.

Поддержать проект

Даже если вы не сможете присоединиться, нас можно поддержать. От сообщества - для сообщества.
Сделайте репост своим коллегам в чатик, закиньте в ваше локальное сообщество питонистов, поделитесь в своем тг канале. Будем рады любой медийной поддержке!

Обсуждение: Что вы реально думаете про текущее состояние платных конференций? Есть ли в них еще хоть какой-то смысл? Я вот думаю, что не особо.

| Поддержать | YouTube | GitHub | Чат |

PEPы в Python окончательно вышли из-под контроля

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

Докстринги для TypeAliasType

PEP-846: https://github.com/python/peps/pull/5116

Базовая база: пишем докстринги после ключевого слова type - у нас появляется __doc__ атрибут.

type Timeout = float | None
"""Maximum wait in seconds. """

Привычный синтаксис из-за sphinx аннотаций для атрибутов.
Кстати, поддержка правила для поиска докстрингов вне правильных мест уже в wps!

Паттерн-матчинг конкретных значений

PEP-845: https://github.com/python/peps/pull/5107

В питоне была проблема, что нельзя сматчить конкретное значение из переменной. Все имена в PM всегда переписываются. В первой версии PEP-622 хотели сделать паттерны для сравнения с переменной, но потом отказались. А без такого - жить довольно сложно.

Такой синтаксис предлагают авторы:

def get_book_titles_for_author(author: str):
        for book in BOOKS:
            match book:
                case {"title": title, "author": .author}:
                    yield title

Обратите внимание на .author, что показывает матч со значением внутри author, а не переназначение переменной author. Если бы добавили $ для "констант", то было $author 🌚
Мне нравится, выглядит полезно.

yield from в асинхронных генераторах

PEP-828: с python3.16 можно будет писать так:

async def agenerator():
    yield 1
    yield 2
    return 3

async def main():
    result = yield from agenerator()
    assert result == 3

Я нейтрален, зависит от сложности реализации и граничных случаев.

Явные public и private декораторы

PEP 844:

# spam.py
@public
class Public:
    ...

@private
class Private:
    ...

# ex.py
import spam
spam.__all__  # ['Public']

Манипуляция __all__ через декоратор. А можно не надо?
Почему? __all__ используется для from spam import * и не для чего больше. __all__ надо закапывать, а не развивать. Более того, декоратор нельзя повесить на имена и тайп-алиасы. Кажется очень непродуманным решением.

Ключевое слово export

PEP-843: Предлагают добавить ключевое слово export для ... я не знаю чего.
А, опять манипуляции __all__. Чем не устраивает простая текущая система? Если имя начинается с _ - то оно protected. Ключевое слово для управления списком! Я против.

Ребята из FastAPI тащат синтаксис для себя в stdlib

PEP-835: Предлагают сделать @ типовым и рантайм оператором для создания Annotated объектов.
Крайне неудачный PEP на мой взгляд, о чем я написал авторам и собрал кучу поддержки.
Не поймите меня неправильно: я всячески за операции над типами. Просто я не думаю, что int @ Field(max=100) должно значить Annotated[int, Field(max=100)]. Нет задачи сократить количество символов, которые мы пишем (а некоторые уже и не пишут).

Одной строкой

- На прошлой неделе я побывал в пресс-туре MAGNIT TECH в Суздале. Было очень круто. Приятно видеть, как развивается ритейл. Обсудил с коллегами умные кассы, внедрение ИИ, новые способы оплаты, предиктивную аналитику спроса, интересное в логистике, предложил им внедрить wps. Хорошо провел время с коллегами @alexgladkovblog, @t0digital, @MrTeamlead. Суздаль - очень красивый! Кароч, очень понравилось. Спасибо за приглашение!
- Мы релизнули dmr@0.15.0 в рамках #opensource_september, все большое спасибо за участие. Наш самый большой релиз. Пока что!
- Про PEP-805 будет отдельный пост
- В Нижний на конфу уже собралось очень много людей из разных городов, приезжайте и вы! Можно даже отбивку о регистрации не ждать, всех пустим :)

Обсуждение: Как вам данные ПЕПы? Нашли что-то полезное для себя?

Монадические выражения в Python. Наконец-то!

Продолжаем разговор про интересные PEPы. Поговорим сразу про два:
- PEP-823: https://peps.python.org/pep-0823
- PEP-824: https://peps.python.org/pep-0824

В целом они оба об одном: использовании ? для решения проблемы обращения к None при работе с данными.

Первый PEP описывает два новых оператора ?. и ?[], которые позволяют представить выражение some?.field как:

if some is not None:
    field = some.field
else:
    field = None

Аналогично: some?[field] будет делать тоже самое, но для для some[field].

Второй - позволяет использовать оператор ?? вместо is not None и тернарных выражений. Теперь мы сможем писать some ?? 'default' вместо some if some is not None else 'default'. И есть вариант ??= по аналогии с +=, тд.

Данная попытка уже не первая. Первая была сделана очень много лет назад в PEP-505, который отклонили.
Но теперь, два данных PEP'а проспонсированы лично Гвидо, так что шансы хорошие.

Примеры

Давайте посмотрим на более реалистичные случаи. Например, если у вас есть вот такая вложенная структура данных, и нужно получить имя покупателя из очень глубокого слоя, то сейчас мы вынуждены писать:

def get_customer_name(data: Data) -> str | None:
    """Get customer name in lower case if it exists."""
    customer = data.customer
    if customer is not None:
        user = customer.user
        if user is not None:
            return user.name.lower()
    return None

Превращается в:

def get_customer_name(data: Data) -> str | None:
    return data.customer?.user?.name.lower()

Как будет работать второй вариант? Если data.customer является None, то мы сразу его возвращаем. Если нет, пробуем получить .user, проверяем его на None. И тд.

Важный момент: __getattr__ и __getitem__ никак не меняются, они просто не вызываются при None.

В большинстве языков (PHP/JS/TS/C#/Kotlin/Swift/Rust/Dart) такая фича уже есть, она делает работу с вложенными опциональными данными сильно удобнее.

Типизация

Ничего не меняется:
- get_customer_name все еще возвращает str | None
- Обращение через . к optional полю - все еще ошибка
- Обращение через ?. к optional полю - не ошибка, а просто None

Перформанс

Самое интересно! Первый вариант get_customer_name выполняет много опкодов на ровном месте.
Условия, сравнения, прыжки, LOAD_ATTR и тд. Что делает данный код сложным для оптимизации и JIT'ирования. Но data.customer?.user?.name.lower() оптимизировать очень удобно, потому что можно сделать один новый опкод LOAD_OPTIONAL_ATTR (или добавить еще один oparg к текущему LOAD_ATTR), а уже его будет очень удобно оптимизировать. Потому что весь код проверок будет жить в одном месте рядом на C, а не куча условий на питоне. И последовательность таких LOAD_OPTIONAL_ATTR будет удобно находить и возможно оптимизировать в том числе.

Почему монадические?

Потому что на заголовок нужно было как-то забайтить! 🌚
Но и контекст, конечно, реально существует. Например в dry-python/returns уже много лет была доступна конструкция Maybe с методом .bind, который ведет себя прямо как ?. оператор и не продолжает выполнение после первого None / Nothing.

Как вы уже поняли, я дикий фанат таких штук. Ждем всем чатом!

Одной строкой

- dmr@0.16.0 почти готов; изменений просто капец сколько. Каждая часть фреймворка вылизывается и становится на порядок лучше. Релиз в конце #opensource_september
- Наша бесплатная конференция 17 октября в Нижнем Новгороде получила двух новых спикеров к 6 текущим. Итого: 8 докладов от топовых питон ютюберов и опенсорсеров! Анонс новых докладов будет в самое ближайшее время. А пока можно регистрироваться
- Обратите внимание, что ждать подтверждения не нужно! Мы стараемся всем сразу высылать письма, но они нужны только для моральной поддержки :) Было много вопросов по статусу письма. Если вы зарегались, то можете приходить! Пустим всех.

Обсуждение: Что вы думаете? Не возникает ли у вас вопросиков по данной фиче? Как вы сейчас решаете данную проблему с boilerplate кодом?

Еще анонсы докладов на бесплатную конференцию 17 октября в НН

Регистрация: https://itgorky.ru/bolshaya-vstrecha

Нам дали впихнуть невпихуемое и дали еще два слота под доклады.
К 6 прошлым докладам. Теперь их 8 на нашей секции.

Наша концепция конференции: ваши любимые опенсорсеры и ютюберы. Ровно их я и пригласил!

- Алексей Голобурдин @t0digital, с канала Диджитализируй: Будущее локальных LLM

Почему для многих задач полностью локальные агенты это будущее, как Microsoft, Apple и hardware-производители идут в сторону локального инференса, и как это использовать разработчику.

- Александр Целуйко, core-разработчик msgspec: Я твой fastapi msgspec'ом ускорял

Почему msgspec быстрее и меньше базовых структур (namedtuple, dataclass и тп) python и orjson (не всегда и везде есстессна).
Что нужно, чтобы fastapi работал на msgspec? Как разогнать Ваш сервис на fastapi ещё быстрее?
Устроим батл про msgspec vs adaptix!

Другие треки

На конференции будут и другие треки!

- Frontend
- DevOps
- InfoSec
- DevRel
- ODS от наших коллег из Нижегородского филиала @nnodsbreakfast
- QA

На них я особо отмечу доклады от моих коллег / друзей:
- DevRel: Ксения Романова @devrel_sklad: Как изменения в разработке уже меняют DevRel
- DevRel: Анастасия Маслова @za_predelami_koda: Не всё, что можно автоматизировать, стоит автоматизировать
- DevRel: Обед с Валентином Домбровским, где он расскажет про строительство сообществ, про мотивацию, про @moscow_python и про MoscowPython Pro
- Frontend: Никита Пастухов @fastnewsdev: Как научить AI красить кнопки

(ха! смотрите, Никита - фронтендер! 🌚)

Тусовка

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

Техническое

- Письмо от нас ждать не надо, мы его высылаем всем. Просто не всем доходит 🌚
- Если зарегались, то смело приходите / приезжайте! Ничего ждать не надо.

Регистрация: https://itgorky.ru/bolshaya-vstrecha
Нижний Новгород, 17 октября

Обсуждение: А какой доклад больше всего ждете вы? С кем больше всего хочется вжарить пивчанского?

Платформа для agentic разработки

Коллеги из GitVerse сегодня выкатили новое большое обновление. Теперь прямо на платформе можно запускать агентов для разных задач, с разным тулингом, на разных моделях.

Я протестировал новые возможности, выглядит очень круто. Я дико люблю GitHub Agents. Пользуюсь им чуть ли не каждый день: обновить зависимость, сделать ревью сложного кода, решить какую-то простую задачу. Мне кажется, что запускать агенты прямо рядом с кодом - лютейшая база. Очень удобно.

Рад, что такая же фича появилась в GitVerse. Делюсь впечатлениями и техническими подробностями. У меня было три разные задачи.

Создание проекта

Для начала я попросил встроенную бесплатную модель GigaCode сделать мне новый проект из моего шаблона для python пакетов.

Пример: https://gitverse.ru/sobolevn/test-ai-agents/issues/1

Как?
1. Включаешь в настойках "AI-Соавтора" GigaCode-разработчика (документация)
2. Создаешь задачу в трекере
3. Назначаешь GigaCode-разработчика на нее, можно просто в kanban таску передвинуть
4. Готово!

Агент сам развернет окружение, решит задачу, пришлет PR.
В интерфейсе можно выбрать модель, добавить дополнительный prompt.
Или можно просто тегнуть в PR и попросить агента доработать что-то.

Проверка задач

Следующий пример: допустим вы хотите научить коллег наконец создавать понятные задачи 🌚️️️️
Можно сделать AI частью вашего workflow, создаем .gitverse/workflows/issue_dor.yml (помните, я писал, что GitHub Actions можно брать и переиспользовать?)

on:
  issues:
    types: [opened]
 
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/ai-developer-action@master
        with:
          prompt_file: .gitverse/prompts/issue_dor.md

Теперь мы можем разместить любой промпт для проверки Definition of Ready в файле .gitverse/prompts/issue_dor.md и агент будет на каждую новую задачу запускаться и выполнять проверку. Работает! Документация.

Пример: https://gitverse.ru/sobolevn/test-ai-agents/issues/3

Опять же, можно выбирать разные модели для разных задач и тут тоже.
Ключевое: вешать агента можно на любые события CI. От релизов до коммитов.

Использование внешней модели

Конечно же мне захотелось попробовать подключить какую-то внешнюю модель и потестить, как работает интеграция на задаче с программированием. Сначала настраиваем AI_SESSION_MODELS переменную:

[
  {
   "profile_id": "gpt-sol",
   "name": "your-provider/api/v1/gpt-6.1-sol",
   "auth_mode": "direct",
   "base_url": "https://your-provider.example/api/v1",
   "model": "openai/gpt-6.1-sol",
   "api_key_secret": "CUSTOM_PROVIDER_KEY",
   "input_modalities": ["text"],
   "output_modalities": ["text"]
  }
]

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

Создаем задачу, назначаем агента, выбираем нашу модель (на скриншоте).
Агент шуршит, присылает результат в PR: https://gitverse.ru/sobolevn/test-ai-agents/pulls/5

Приятные бонусы

- Чаты и сессии с агентами
- Собственные агенты и кастомные скиллы
- Поддержка кастомных MCP
- Свой MCP для работы с GitVerse API
- Интеграции с IDE
- Разбор ошибок CI
- Генерация сообщений к коммитам
- Удобный UI для обращения к агентам из любого места на сайте

Выглядит круто! Попробуйте для своего проекта.

Обсуждение: Какие фичи платформы для агентской разработки для вас наиболее нужны и важны? Какие модели там вы предпочитаете?

Реклама. ПАО "СБЕРБАНК", ИНН 7707083893. erid: 2W5zFHAvuSq

Доклады с большой встречи сообщества

17 октября мы провели большую встречу сообщества. Надеюсь, успешно!

Доклады: https://www.youtube.com/playlist?list=PLbr8rVGhPD0WJxhx-Sc2In7OMGJndsQ4f

Немного статистики:
- 1000+ человек на всей конференции
- 300+ человек на @pytho_nn части
- 125 человек в тусочате
- 7 крутых докладов
- 4 занятых бара
- десятки новых интересных знакомств
- половина нашего чата приехала

Большое спасибо всем, кто помогал делать нашу конфу:
- Нашему главному организатору Игорю, что вытащил такой проект @it52info
- Замечательным фотографам Екатерине (фотки от нее тут) и Ярославу (фотки от него)
- Всем волонтерам, кто помогал со всеми практическими задачами
- Ведущему, Леха - красава!
- Конечно же спикерам, (по ссылкам можно почитать их отзывы): Иван, Егор, Алексей Гладких, Сергей Макаров, Максим, Алексей Голобурдин, Никита, Валентин, и все-все-все. Спасибо вам большое! Было интересно, было полезно, был повод для дискуссии. Под некоторыми докладами настоящий бомбеж в комментах 🌚️️️️
- Гостям! Люди специально приехали из Минска, Махачкалы, Тюмени, Уфы, Самары, Коврова, Питера, Ростова, Москвы, Нижнего Новгорода, других городов. Вы все просто лучшие! Спасибо за ваш интерес, все отметили, что на конфе чувствовалась душа. Потому что все приехали сами, потому что хотели. Никого не отправляла компания потусить за деньги

Было несколько минусов, которые мы постараемся пофиксить на следующий год: шум у главного зала, очереди за едой и в целом логистика еды, вместимость бара подвела (мы планировали 60-70 человек, но было больше 150). Следующий раз выкупим самый большой бар рядом! Попробуем найти партнера вечеринки.

Доклады: https://www.youtube.com/playlist?list=PLbr8rVGhPD0WJxhx-Sc2In7OMGJndsQ4f

Еще раз: лучшее сообщество! Жду всех в следующем году!

Обсуждение: Как вам конференция? Как вам Нижний? Какой доклад понравился больше всего? Кого бы вы хотели видеть в следующем году в качестве спикеров?

Делитесь фотками в комментах!

Что происходит с ИИ в опенсорсе?

Пост можно было бы назвать "Not so OpenSource anymore". Массовое использование ИИ моделей в опенсорсе привело к масштабным изменениям. Мне почему-то очень грустно от таких новостей. Пусть и вам будет!

Мой доклад про то же самое: https://www.youtube.com/watch?v=oHIgRZNpS00

- CPython ограничил количество PRов от внешних контрибьюторов тремя открытыми
- OpenJDK запретил PRы с использованием ИИ в любом виде
- Litestar закрыл PRы для всех внешних контрибьюторов, поток слопа был настолько большой, что я в какой-то момент просто бросил открывать уведомления в проекте. Максим написал большой пост про данный случай
- JazzBand после 10 лет открытой коллаборации для десятков проектов закрылся по их формулировке из-за "слопаппокалипсиса", новые участники больше не принимаются
- Sindre Sorhus (один из самых популярных опенсорс разработчик в мире) закрыл все свои проекты для внешних контрибьюторов
- JS фреймворк hono закрывает внешние PRы
- Браузер LadyBird закрывает внешние PRы
- Godot запретил использование ИИ
- Платформа Codeberg объявила себя свободной от LLM-сгенерированного контента
- Zig запретил использование ИИ у себя (читайте полную историю про переписывание Zig -> Rust и при чем тут bun)
- Node.js будет молча закрывать PRы с ИИ-слопом
- Linux прекращает поддержку старых сетевых драйверов, чтобы справиться с количеством ИИ-багрепортов

Есть только один вопрос: как проекты, которые "запретили" ИИ будут такое контролировать?

GitHub

Сама платформа тоже меняется. Местами развивается, местами работает с каждым днем все хуже и хуже: от UI до CI.

- GitHub все время падает под нагрузкой (с их слов)
- GitHub ввел функцию количественного ограничения количества PRов от внешних контрибьюторов для всех репозиториев, потому что проблема массовая
- У GitHub больше нет CEO, теперь они часть Microsoft AI
- Массовая миграция проектов с GitHub: Gentoo, Zig, Ghostty, BookStack, Flathub, Tenacity

BugBounty умирает

Ну и конечно же проекты и компании закрывают программы BugBounty для внешних участников.

- curl как самый известный пример
- Google OSS VPR закрыт в октябре, Intel закрыл свою программу в сентябре
- HackerOne закрылся

Продвижение и сообщество

Я больше не знаю, как продвигать новый опенсорс (кроме постов в нашем чате с тегом #opensource конечно же) . Большинство старых площадок вводят суровые правила против постов со ссылками на свои проекты:

- r/Python запретил публикацию своих проектов, мой пост с анонсом django-modern-rest был удален автоматически
- r/opensource запретил публиковать AI-slop проекты, формулировки у них вышли очень странные и размытые
- Hacktoberfest больше не считает PRы, теперь только митапы
- Культура "Good first issue" мертва. Теперь на такой тег приходят только боты

Польза

Но! После всех новостей важно не впадать в думерство. Польза от ИИ в опенсорсе тоже есть.
Недавние находки критических уязвимостей в PHP, Node, GitLab - доказывают пользу грамотного использования ИИ.
Многие проекты созданы только благодаря ИИ. Оптимизации, помощь в объяснении исходников, поиск багов, мертвого кода и несоответствий документации и кода. А сколько полезных маленьких проектов люди навайбкодили для себя?

Давайте держаться здравого баланса. Искать технические ответы на возникающие сложности и вопросы.

Опенсорс - каким мы его знали - мертв.

Вывод: необходимо перестраивать систему. Как? Предлагайте в комментариях, обсудим.