Когда regex ломает сборку: охота на призрака в version.py

Работаю над Speech to Text — проект с поддержкой CUDA-сборок для GPU-ускорения. Наша система так устроена: CI собирает CPU-версию, а локально я публикую CUDA-релизы через publish_cuda.sh. Скрипт берёт версию из src/version.py, упаковывает всё, подписывает ed25519-ключом и отправляет на зеркало. Казалось бы, рутина.

Но вот беда: при публикации версии 2.0.9 сборка начала брать неправильный номер версии. build.py читает версию через regex, и вместо 2.0.9 собралась какая-то X.Y.Z. Первый подозреваемый — src/version.py. Открываю файл… aha! В файле была строка-пример в docstring-е: "X.Y.Z". И regex в build.py её нашла! Это была классическая проблема: regex ищет __version__ = "...", но не якорится к началу строки, так что подхватывает даже примеры в комментариях.

Первый фикс: переместить настоящий __version__ = "2.0.9" в самое начало файла как первое присваивание. Второй фикс: в самом build.py добавить якорь ^ с флагом re.MULTILINE в regex. Теперь он ищет присваивание только в начале строки — пример в docstring больше не сбивает с толку.

Но ладно, сборка прошла. Дальше — запуск на Windows. И тут выясняется, что в voice_app.spec в какой-то print-строке была стрелка Unicode →, и консоль Windows в кодировке cp1251 не может её вывести. Падает. Заменяю на -> — готово.

Такие мелочи в публикации релизов выглядят наивными, пока не сломают процесс. Regex без якорей, примеры в docstring-ах, которые мешают парсингу, Unicode в местах, где ожидают ASCII — всё это живёт где-то на грани видимости. Поэтому когда что-то вдруг не работает при локальной сборке, стоит смотреть не на сложные части, а на простые: как именно код читает данные, что находится рядом с этими данными, и включает ли парсер якори для границ.

Кстати, про yakori — напомнило мне шутку про Kubernetes 😄 Почему Kubernetes лучший друг разработчика? Потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить.