Определите ответвления пакета Python изнутри

У меня есть пакет Python (приложение с графическим интерфейсом PyQt) на Github, опубликованный через PyPI. Он имеет средство сообщения о сбоях. Время от времени я получаю сбои, которые слегка, но безошибочно несовместимы с моим кодом.

Примеры: ошибка «класс X не найден в модуле Y», когда модуль зависимостей Y был недавно обновлен путем добавления класса X, и я изменил строку зависимости в setup.py, чтобы ссылаться на последнюю. Другой пример включает в себя конкретное исключение, о котором сообщается, что оно выдано в строке 78, хотя в моем коде, в этой конкретной версии, raise находится в строке 80.

У меня есть сильное подозрение, что эти сбои происходят из-за сторонних вилок. GitHub говорит, что у него есть 8 форков.

В любом случае, мой вопрос: могу ли я как-то идентифицировать отчеты о сбоях, которые исходят от сторонних вилок, а не от моих сборок?

🤔 А знаете ли вы, что...
Python используется в научных вычислениях и обработке изображений с использованием библиотеки OpenCV.


3
53
1

Ответ:

Решено

Вот что я придумал. Я представил файл 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), но все же.