Models bundled in wheel are fetched from an old release asset (v1.1.0) during CI

[vshawrh]

Body:

Summary

The wheel build workflow (gen_whl_to_pypi_rapidocr.yml) downloads ONNX model files from a release asset attached to the v1.1.0 release (from August 2022):

env:
RESOURCES_URL: https://github.com/RapidAI/RapidOCR/releases/download/v1.1.0/required_for_whl_v3.0.0.zip

This zip (required_for_whl_v3.0.0.zip) is then extracted and the model files are copied into the wheel at build time. The git repository itself only has an empty python/rapidocr/models/ directory with a .gitkeep file.

This pattern has been the same since at least v3.0.0 through the current v3.8.1.

Concerns
Fragile dependency on old release: Every new version's wheel depends on assets attached to the v1.1.0 release from 2022. The release itself has a warning (these attachments cannot be deleted, many things depend on them). If this release or its assets are ever removed or modified, all future wheel builds break.

Models not versioned with source: The models are not tracked in git or versioned alongside the code. There's no way to determine from a given source tag which models were used to build that version's wheel, other than reading the CI workflow file.

Difficult for downstream builders: Anyone building the wheel from source (e.g. Linux distributions, enterprise rebuilds) must fetch this external binary asset from a GitHub release during the build. This breaks offline/air-gapped builds and makes it harder to audit the full contents of the wheel.

No sdist available: The package only publishes wheels on PyPI, not source distributions. Combined with the external model download, this makes it impossible to build purely from PyPI-provided artifacts.

[SWHL]

Thank you for pointing out the problem. As the default model has remained unchanged all along,

I haven’t carried out targeted optimization for this part yet.I’d love to hear your suggestions.

I’m fully willing to optimize this section to improve its robustness.