У меня есть пакет Python (приложение с графическим интерфейсом PyQt) на Github, опубликованный через PyPI. Он имеет средство сообщения о сбоях. Время от времени я получаю сбои, которые слегка, но безошибочно несовместимы с моим кодом.
Примеры: ошибка «класс X не найден в модуле Y», когда модуль зависимостей Y был недавно обновлен путем добавления класса X, и я изменил строку зависимости в setup.py, чтобы ссылаться на последнюю. Другой пример включает в себя конкретное исключение, о котором сообщается, что оно выдано в строке 78, хотя в моем коде, в этой конкретной версии, raise
находится в строке 80.
У меня есть сильное подозрение, что эти сбои происходят из-за сторонних вилок. GitHub говорит, что у него есть 8 форков.
В любом случае, мой вопрос: могу ли я как-то идентифицировать отчеты о сбоях, которые исходят от сторонних вилок, а не от моих сборок?
🤔 А знаете ли вы, что...
Python используется в научных вычислениях и обработке изображений с использованием библиотеки OpenCV.
Вот что я придумал. Я представил файл Python cookie.py
с переменной-заполнителем:
cookie=False
И поместил его в систему контроля версий как есть, со значением cookie False
. В процессе сборки я помещаю последний хэш фиксации в файл cookie, например:
git log --pretty=format:%%H -n 1 >hash.txt
set /p HASH= <hash.txt
echo cookie='%HASH%' >cookie.py
После этого я собираю пакет и возвращаю содержимое cookie.py в состояние с помощью False
. Кроме того, я сохраняю копию хэша коммита и текущую версию пакета в файл истории. Таким образом, пакет в PyPI, который происходит из моих сборок, всегда имеет файл cookie, а файлы cookie можно отследить до выпусков.
Наконец, я делаю значение файла cookie частью отчета о сбое. Если сбой происходит с пустым файлом cookie, неизвестным файлом cookie или файлом cookie неправильной версии, я буду знать, что это не мой файл, или, по крайней мере, исходит от пользователя, который запускает пакет из источников, а не получает его из PyPI. Последнее - крайний случай, с которым я готов жить.
Эта схема далеко не надежна :) На самом деле, ее легко подделать, поскольку хэши коммитов являются общедоступной информацией, а скрипт сборки также имеет открытый исходный код. Но это требует некоторого усилия, и потенциальный спуфер не получит никакой отдачи, поэтому я полагаю, что никто не станет утруждаться дополнительными усилиями.
Примечание: %%H
в команде Git является артефактом командной строки Windows, в *nix/MacOS это будет %H
.
Одним весьма теоретическим недостатком этого подхода является то, что сборка PyPI происходит из набора файлов Python, которые не соответствуют, байт за байтом, зафиксированному состоянию репозитория. Я не понимаю, как это может преследовать меня (особенно в проекте Python), но все же.