Восстановить установку sherpa-onnx на Linux #27

New Issue

2026-08-28T23:25:33+03:00

ddmitry commented

2026-08-28 23:25:33 +03:00

Проблема

После успешного uv sync на Linux установка остаётся несогласованной:

uv pip check сообщает, что для sherpa-onnx==1.13.5 отсутствует обязательный sherpa-onnx-core==1.13.5;
минимальный import sherpa_onnx падает с ImportError: libonnxruntime.so: cannot open shared object file;
сбой происходит до выбора ONNX Runtime provider и до любого обращения к CUDA;
изменения задачи #7 не затрагивают pyproject.toml, uv.lock, модуль диаризации или падающий тест и не являются причиной регрессии.

Цель

Восстановить корректную чистую установку проекта на Linux, при которой runtime-зависимость диаризации разрешается и импортируется согласованно.

Критерии приёмки

Причина расхождения между resolution, platform markers и метаданными wheel доказана по lock-файлу и метаданным пакетов.
pyproject.toml и uv.lock согласованы.
В чистом Linux-окружении проходят:
- uv sync;
- uv pip check;
- import sherpa_onnx;
- целевой тест диаризации;
- полный набор тестов проекта.
Разрешение зависимостей для Windows не сломано; проверка и её ограничения зафиксированы явно.

Вне рамок

Поддержка аппаратно сломанной CUDA на текущем ноутбуке.
Поддержка старого GPU и старых драйверов.
Изменение поведения CUDA или выбор GPU provider.

## Проблема После успешного `uv sync` на Linux установка остаётся несогласованной: - `uv pip check` сообщает, что для `sherpa-onnx==1.13.5` отсутствует обязательный `sherpa-onnx-core==1.13.5`; - минимальный `import sherpa_onnx` падает с `ImportError: libonnxruntime.so: cannot open shared object file`; - сбой происходит до выбора ONNX Runtime provider и до любого обращения к CUDA; - изменения задачи #7 не затрагивают `pyproject.toml`, `uv.lock`, модуль диаризации или падающий тест и не являются причиной регрессии. ## Цель Восстановить корректную чистую установку проекта на Linux, при которой runtime-зависимость диаризации разрешается и импортируется согласованно. ## Критерии приёмки - Причина расхождения между resolution, platform markers и метаданными wheel доказана по lock-файлу и метаданным пакетов. - `pyproject.toml` и `uv.lock` согласованы. - В чистом Linux-окружении проходят: - `uv sync`; - `uv pip check`; - `import sherpa_onnx`; - целевой тест диаризации; - полный набор тестов проекта. - Разрешение зависимостей для Windows не сломано; проверка и её ограничения зафиксированы явно. ## Вне рамок - Поддержка аппаратно сломанной CUDA на текущем ноутбуке. - Поддержка старого GPU и старых драйверов. - Изменение поведения CUDA или выбор GPU provider.

ddmitry added the ready-for-agent label 2026-08-28 23:25:33 +03:00

ddmitry commented

2026-08-29 00:04:44 +03:00

Диагностика #27

Причина

В базовом uv.lock у sherpa-onnx==1.13.5 не было зависимости от core-пакета. Опубликованные артефакты этой версии содержат разные метаданные:

sdist не содержит Requires-Dist; в setup.py зависимость добавляется только при сборке с SHERPA_ONNX_SPLIT_PYTHON_PACKAGE;
sherpa_onnx-1.13.5-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl и sherpa_onnx-1.13.5-cp313-cp313-win_amd64.whl объявляют Requires-Dist: sherpa-onnx-core==1.13.5;
Linux armv7 wheel эту зависимость не объявляет.

В чистом минимальном проекте uv 0.12.6 при построении универсального lock-файла выбрал метаданные sherpa_onnx-1.13.5-cp313-cp313-linux_armv7l.whl, запросил .whl.metadata этого wheel и сообщил Received built distribution metadata. Этот wheel не объявляет Requires-Dist, поэтому core не попал в lock. На Linux x86_64 расширение _sherpa_onnx затем не находило libonnxruntime.so, который поставляется в wheel core-пакета. Сбой происходил при загрузке ELF, до выбора провайдера ONNX Runtime. Код CUDA в этом воспроизведении не выполнялся.

Исправление

sherpa-onnx закреплен на 1.13.5. Блок tool.uv.dependency-metadata для этой версии восстанавливает ребро sherpa-onnx -> sherpa-onnx-core==1.13.5, после чего lock сгенерирован заново. Этот override относится только к uv и не попадает в метаданные wheel самого проекта.

Версию в зависимости, версию в override и требование к core нужно считать одной настройкой. При обновлении sherpa их нужно менять или удалять вместе, затем проверять uv tree --locked --package sherpa-onnx. Контрольный uv lock --upgrade без точного ограничения выбрал sherpa-onnx==1.13.6 и снова потерял core.

Linux

Проверено на Linux, CPython 3.13.13, uv 0.12.6, в новом окружении:

uv sync --frozen: установлены 44 пакета, включая основной и core-пакет версии 1.13.5;
uv pip check --python <clean-env>/bin/python: все 44 пакета совместимы;
прямой import sherpa_onnx: успешно;
pytest -q tests/test_speaker_diarizer.py: 5 passed;
pytest -q: 282 passed, 2 skipped.

Windows

uv sync --locked --dry-run --python-platform windows, запущенный на Linux с uv 0.12.6, разрешил 45 пакетов и выбрал sherpa-onnx==1.13.5 вместе с sherpa-onnx-core==1.13.5. В lock есть core wheels для win32, win_amd64 и win_arm64.

Это только проверка разрешения зависимостей. Реальная установка на Windows, загрузка DLL и import sherpa_onnx не запускались. Оставшийся риск снимается отдельной проверкой на Windows: uv sync, uv pip check и прямой импорт.

## Диагностика #27 ### Причина В базовом `uv.lock` у `sherpa-onnx==1.13.5` не было зависимости от core-пакета. Опубликованные артефакты этой версии содержат разные метаданные: - sdist не содержит `Requires-Dist`; в `setup.py` зависимость добавляется только при сборке с `SHERPA_ONNX_SPLIT_PYTHON_PACKAGE`; - `sherpa_onnx-1.13.5-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl` и `sherpa_onnx-1.13.5-cp313-cp313-win_amd64.whl` объявляют `Requires-Dist: sherpa-onnx-core==1.13.5`; - Linux armv7 wheel эту зависимость не объявляет. В чистом минимальном проекте uv 0.12.6 при построении универсального lock-файла выбрал метаданные `sherpa_onnx-1.13.5-cp313-cp313-linux_armv7l.whl`, запросил `.whl.metadata` этого wheel и сообщил `Received built distribution metadata`. Этот wheel не объявляет `Requires-Dist`, поэтому core не попал в lock. На Linux x86_64 расширение `_sherpa_onnx` затем не находило `libonnxruntime.so`, который поставляется в wheel core-пакета. Сбой происходил при загрузке ELF, до выбора провайдера ONNX Runtime. Код CUDA в этом воспроизведении не выполнялся. ### Исправление `sherpa-onnx` закреплен на `1.13.5`. Блок `tool.uv.dependency-metadata` для этой версии восстанавливает ребро `sherpa-onnx -> sherpa-onnx-core==1.13.5`, после чего lock сгенерирован заново. Этот override относится только к uv и не попадает в метаданные wheel самого проекта. Версию в зависимости, версию в override и требование к core нужно считать одной настройкой. При обновлении sherpa их нужно менять или удалять вместе, затем проверять `uv tree --locked --package sherpa-onnx`. Контрольный `uv lock --upgrade` без точного ограничения выбрал `sherpa-onnx==1.13.6` и снова потерял core. ### Linux Проверено на Linux, CPython 3.13.13, uv 0.12.6, в новом окружении: - `uv sync --frozen`: установлены 44 пакета, включая основной и core-пакет версии 1.13.5; - `uv pip check --python <clean-env>/bin/python`: все 44 пакета совместимы; - прямой `import sherpa_onnx`: успешно; - `pytest -q tests/test_speaker_diarizer.py`: 5 passed; - `pytest -q`: 282 passed, 2 skipped. ### Windows `uv sync --locked --dry-run --python-platform windows`, запущенный на Linux с uv 0.12.6, разрешил 45 пакетов и выбрал `sherpa-onnx==1.13.5` вместе с `sherpa-onnx-core==1.13.5`. В lock есть core wheels для win32, win_amd64 и win_arm64. Это только проверка разрешения зависимостей. Реальная установка на Windows, загрузка DLL и `import sherpa_onnx` не запускались. Оставшийся риск снимается отдельной проверкой на Windows: `uv sync`, `uv pip check` и прямой импорт.

ddmitry referenced this issue from a commit

2026-08-29 00:43:15 +03:00

fix(deps): восстановлена установка sherpa-onnx в Linux

ddmitry referenced a pull request that will close this issue

2026-08-29 00:44:09 +03:00

fix(deps): восстановлена установка sherpa-onnx в Linux #28

ddmitry referenced this issue from a commit

2026-08-29 01:21:34 +03:00

fix(deps): восстановлена установка sherpa-onnx в Linux

ddmitry closed this issue

2026-08-29 08:49:10 +03:00

Sign in to join this conversation.