Погулил что за буква t.
Буква t это free-threaded сборка, тот же Python, но без GIL. У неё другой ABI, cp314t. И колёс под cp314t у grpcio нет ни одного. Поэтому uv честно говорит, что готового бинаря под мой экзотический питон не завезли, и идёт собирать из исходников. На всех ядрах. Дважды.
Самое обидное: будь у меня обычный 3.14, взялось бы готовое колесо cp314 и ничего бы не грелось. Меня наказала именно free-threaded сборка, которую я когда-то поставил глобально. Когда и зачем именно её, я вспомнил не сразу, но к этому вернёмся в самом конце.
Лечение. Снёс нагрузку через pkill по билд-процессам, CPU сразу в ноль. Дальше, чтобы не повторялось, пинаю opensearch нормальный, не-free-threaded питон прямо в
~/.cursor/mcp.json:"opensearch-homelab": {
"command": "uvx",
"args": [
"--python", "3.13",
"opensearch-mcp-server-py"
],
...
}Проверяем, что под 3.13 всё ставится из готовых колёс:
uvx --python 3.13 --from opensearch-mcp-server-py python -c "import grpc; print(grpc.version)"
Downloaded grpcio
Installed 61 packages in 107ms
grpc 1.81.0 on 3.13.12
107 миллисекунд вместо двадцати минут компиляции. Ни одного clang.
Вот и вся разница между есть колесо под твой ABI и нет колеса под твой ABI.
Маленькая засада на сладкое. После того как я убил билд, курсор его тут же воскресил, но по старому конфигу, потому что новый mcp.json он ещё не перечитал. И я снова увидел компиляцию под 3.14t. Лечится тривиально: выключить-включить MCP-серверы в настройках Cursor или рестартнуть его, чтобы он подхватил python 3.13. После этого opensearch стартует на 3.13 мгновенно, кэш уже тёплый.
Первый подозреваемый, тот, что висит живым и на виду, почти никогда не виновник. mcp-grafana чуть не сел за чужое. Обнуляй факты и иди по цепочке зависимостей до конца.
Транзитивные зависимости умеют больно бить. Ты ставишь MCP для опенсёрча, а получаешь сборку gRPC из исходников через два промежуточных пакета, про которые ты даже не знал. Я вообще блять ничего не понимаю почему такая реализация.
Экзотика в окружении, free-threaded питон глобально, аукается там, где не ждёшь. ABI cp314t это не cp314, и весь мир пакетов, у которых нет колёс под no-GIL, начинает собираться из сорцов прямо у тебя на коленке.
Проблема найдена, объяснена на 100%, пофикшена и закрыта. Кулеры выдохнули.
Но остаётся ворпос: а откуда вообще взялся питон с буквой t.
Раз уж вся боль из-за free-threaded сборки, логичный вопрос: кто и когда вхерачил её мне глобально.
Тут я снова не стал гадать, а пошёл по следам в файловой системе и в истории шелла.
Дата рождения каталога сборки в asdf:
stat -f '%SB' ~/.asdf/installs/python/3.14.3t
Mar 17 20:56:52 2026
То есть поставлено 17 марта 2026, вечером. А кто. Да я же сам, руками, в своём терминале. Вот честный след из
~/.zsh_history того же вечера:asdf plugin add python
asdf install python latest
asdf global python latest
asdf set -u python 3.14.3t
Последовательность красивая: добавил плагин, поставил latest, а потом отдельной командой явно прибил глобально именно 3.14.3t. Буква t стоит прямо в команде, то есть это был осознанный выбор конкретной no-GIL сборки, а не случайный дефолт. И в asdf с тех пор так и живёт ровно одна версия питона, вот эта.
Почему? Да хер его знает, не удивлюсь, если это агент ставил, а я тупо копипастил.🦍
- - -
Так что же там у нас с бобиной?
А, ну да, там же есть полное продолжение.
Мы сидели и вникали,
Разбирали, собирали,
Замеряли, вычисляли,
Днями, сутками, ночами.
Умножали и делили,
Выбирали "или-или",
Но машина всё ж не едет.
Что за козни? Что за бредни?
Мы по новой за расчёты:
Может, там у нас просчёты,
Может, что-то упустили,
Не нашли, не уследили...
Вдруг не то мы вычисляли
Днями, сутками, ночами.
Но машина вновь не едет,
Инженер наш главный бредит.
Снова мы на путь тернистый
Должен быть расчёт уж чистый.
Умножаем, вычисляем,
алгоритмы составляем.
Только было всё напрасно
Лишь потом нам стало ясно:
Дело было не в бобине
Долбоёб сидел в кабине.