RapidOCR AUR package

so, one/two weeks/worth in one devlog, come at me.

usually to accommodate a new upstream update, all you need is to put in the checksum for the new tarball download. but this time RapidOCR decided to finally replace their deprecated setup.py building with PEP 517 (a.k.a. normal Python packaging).
they also used to rely on the user downloading a zip file of the models for the bundled configuration from the artifacts for v1.1.0—no way to tell when you’d need to redownload that! it seems upstream relied on the user only needing to download from PyPI, which to be fair is the vast majority of usecases—lucky for non-Arch-ers, not lucky for me.
⁂

so figuring out the commands to replace python setup.py build with was the easy part: it’s called “standards-based packaging” because the command is python -m build --wheel --no-isolation no matter what exactly the pyproject.toml does. one small problem: the build needs a version, which RapidOCR provides dynamically by reading the latest tag from git. as you may realize, git information is not included in the tarball downloads typically used for such large repos, including in this package. thankfully this was even easier to patch out than setup.py’s behavior to fetch the version from PyPI (what)
⁂

next was the new way to download models. apparently all it took for the change was someone to complain that the process was “opaque” (not the word I’d use). it’s true that it was difficult to verify… but at least it was easier to wrap your head around than its replacement: a 133-line Python script!
i tried to follow its code around but eventually my feeble line decided its takings were excessively HIGH (ooh the G in the font is cool). so i exercized the reverse-engineer’s first approach: run it and see what it does. it downloaded three models and from my reading of the code, it seemed to reference a default_models.yaml. sure enough, all the download links were in there.
thus the obvious approach was to also download these links and update them every release. and it worked! after the minor hiccup of needing a MANIFEST.in to tell python -m installer to also ship the model files in the wheel we would install.
⁂

it’s through this yaml-reading that I discovered how RapidOCR in fact supported a ton of different models. there were nearly 300 options mentioned by default_models.yaml alone! ordinarily python-rapidocr would be able to search this directory of models and download them, but on Arch it’s installed into a system directory that it cannot modify. same for the config file. so I thought I could simply get at least the configuration part to work by symlinking it from /etc (and thus improve the discoverability of this feature).
it turned out this would break upgrading the package, and only on Arch would it break upgrading the package. i first heard this “attempting to write {config file} outside the target directory” bug in a vague comment raised by another AUR user who used Claude to give a completely incorrect blathering on how to fix it, which is exactly why I somehow decided to run Claude myself.
I wouldn’t have been able to discover the issue’s location by myself… as the bug was in fact within python -m installer! the 1.0.0 release used Path.resolve() to validate paths. if said path actually did exist on the system as a symlink, resolve() would output the ultimate target of that symlink instead of only eliminating ./s and ../s. and thus python -m installer followed the symlink to /etc/ which was decidedly outside /usr/.
the solution is to force people to build the 1.0.1 release (which accidentally fixed this bug by optimizing the resolve() step) because Arch for some reason hasn’t yet shipped this update from May… because though its PMs are all hella chill and nice, the sole maintainer is kinda on vacation
vote me for package maintainer