23.4k звёзд, а pivot не сработал: боевой тест OfficeCLI

Двадцать три с половиной тысячи звёзд на GitHub. Версионированный URL, SHA256, без sudo. Аудит пройден на пятёрку. И всё равно в бою половина фич сломана.

Поставил OfficeCLI v1.0.143, инструмент для работы с Excel из командной строки. Сначала аудит: 23.4k звёзд, Apache-2.0, скрипт установки вместо слепого curl | bash скачал в /tmp и перечитал глазами. Неизменяемый URL, проверка SHA256 по SHA256SUMS, атомарная замена, подпись Developer ID, пишет только в ~/.local/bin и скиллы. Ни sudo, ни launchd, ни кронов. Эталонный процесс установки.

Потом боевой тест: собрать сводную xlsx из CSV с условным форматированием топ-3. И тут звёзды перестали иметь значение. create, open, save, raw-set работают. А import вернул пустые ячейки, query не фильтрует, pivottable упал с «source range not found». Три из шести проверенных фич мертвы.

Обходной путь: данные залил через raw-set с awk-агрегацией. Сработало, но это костыль. Вердикт: watch-list, перепроверить на следующем релизе. Основной инструмент для xlsx остался Python с openpyxl.

Правило: звёзды это маркетинг, а не тесты. Единственный честный аудит это боевой прогон на твоих данных.

Апдейт от 31.08. Комментатор @amenner задал правильный вопрос про минимальный воспроизводимый пример. Прогнал — и картина стала точнее. import и pivottable: симптомы не воспроизводятся даже с дословными боевыми вызовами; вероятные причины былых провалов — import в несуществующий файл (сначала create) и CSV с ; из русской локали Excel (разделитель фиксирован, --delimiter нет — feature-request #352). Pivot, видимо, падал вторично — источник был пуст после «мёртвого» import. query: а тут amenner прав лишь частично — псевдоклассы :lt(N)/:nth-child() молча возвращают все строки, это подтверждённый живой баг с ложным exit=0 (issue #351); рабочий синтаксис — row[поле>значение]. Итог: две «мёртвые фичи» оказались нюансами вызова, одна — настоящим багом. Правило дня теперь двустороннее: звёзды — маркетинг, но и «сломано» — не диагноз без минимального стенда.

Апдейт от 01.09. Мейнтейнер закрыл оба issue в день подачи — и ответы стоят отдельного упоминания. По #351: настоящий дефект был глубже моего репорта — фильтр contains вообще не применялся ни к одному типу элементов, кроме ячеек; :lt(2) парсился как «содержит текст lt(2)» и должен был вернуть ноль строк, а возвращал все. Фикс dc532e89, заодно query --help теперь перечисляет реальную грамматику селекторов (позиционные :lt/:nth-child не реализованы; есть row[N]). По #352: шипнуто с бонусом — мейнтейнер подхватил ремарку про ru-RU и добавил не только --delimiter ";", но и --decimal ",", потому что разделитель ; существует именно из-за десятичной запятой. А при триаже вскрылся баг хуже моего: 1,5 молча сохранялось как 15 — .NET-парсер тысячных разделителей не валидирует группы, и десятичные значения умножались на 10/100 без единого предупреждения. Починено (b46eb308, 18e14c24) во всех слоях — хранилище, формулы, pivot, сортировка. Итог истории: один вопрос в комментариях → минимальный стенд → два issue → три фикса в апстриме за сутки, включая баг, который никто не репортил. Вердикт по инструменту: меняю на adopt с релиза > 1.0.145. Правило остаётся двусторонним: звёзды — маркетинг, «сломано» — не диагноз без стенда, а хороший репорт с контрольным примером — это вклад, который мейнтейнеры цитируют в ответе.