Repository navigation
fix(cli): keep convert-remote working on docling-client installs - #4803
Conversation
Building the OCR, layout, and table engine factories loads the built-in plugins, which import the engine modules. On docling-client / docling-slim[service-client] installs these imports fail (packaging, torch), so the docling CLI crashed at startup, also for `docling convert-remote --help`. Guard the factory construction together with the factory import. When the local model stack is missing, `docling convert` and `--show-external-plugins` now exit with an install hint instead of a traceback. Signed-off-by: Michele Dolfi <dol@zurich.ibm.com>
|
✅ DCO Check Passed Thanks @dolfim-ibm, all your commits are properly signed off. 🎉 |
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
AI triage (advisory)Checked commit This pull request prevents import errors when users run Topic labels added: CI safety: no concern found. A maintainer must still approve CI. 1 related pull request(s) in the same code
The |
There was a problem hiding this comment.
AI first review (advisory): no blocker found
This review covers the full diff at c9483fe239. It read the code and did not run it.
I found no defect that decides the merge. In docling/cli/main.py the import guard now also covers building the OCR, layout, and table factories, which is where the packaging and torch imports fail. convert and --show-external-plugins exit with code 1 and an install hint when the stack is missing. Two things are not covered: the old module-level names ocr_factory_internal, layout_factory_internal, and table_structure_factory_internal are gone, and nothing else in the repo uses them. The --show-external-plugins exit path has no test. This second gap is minor.
A maintainer makes the merge decision. This review never approves the pull request.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
pip install docling-clientinstalls thedoclingCLI, but the CLI crashed at startup, also fordocling convert-remote --help. The CLI module builds the OCR, layout, and table engine factories at import time. This loads the built-in plugins, which import the engine modules. Ondocling-slim[service-client]installs these imports fail (packaging, thentorch). The existing guard only covered the factory import, not the factory construction.Changes:
docling/cli/main.py: build the factories inside the sametry/except ImportErroras the factory import. Keep the error.docling convertand--show-external-pluginsnow exit with code 1 and an install hint (pip install docling, ordocling convert-remote) when the local model stack is missing. Before, they showed a traceback.docling convert --helpstill lists the available engines.Checklist:
service-clientis enough forconvert-remote.)Review evidence:
Before: in a fresh venv with only
docling-clientinstalled,docling convert-remote --helpfails withModuleNotFoundError: No module named 'packaging'fromdocling/models/inference_engines/vlm/_utils.py, throughget_ocr_factory()indocling/cli/main.py.After, same venv (
uv pip install ./packages/docling-client ., notorch, nopackaging):docling convert-remote --help: exit 0, help shown.docling convert-remote file.pdfagainst an unreachable URL: reaches the service client and reportsCannot reach service.docling convert file.pdf: exit 1 with the install hint.docling --version: works.Tests:
test_cli_main_importable_without_local_model_stackwith two tests that run the CLI in a subprocess withpypdfium2,scipy,torch, andpackagingblocked:convert-remote --helpmust succeed, andconvertmust exit 1 with the install hint. The subprocess keeps the blocked and re-imported modules out of the other tests (an in-process version pollutedtests/test_cli_remote.py). Both tests fail without the fix.uv run pytest tests/test_cli.py tests/test_cli_remote.py tests/test_cli_tools.py: 139 passed.make validate: passed.