fix(help): resolve version without raising when metadata is absent (#191)

[robcohen]

Summary

Fixes #191 — the Help page returns HTTP 500 (PackageNotFoundError: No package metadata was found for rustfava) on packaged installs (e.g. the .deb).

Root cause

help_page called importlib.metadata.version("rustfava") with no fallback. Packaged builds (PyInstaller sidecar, .deb) ship the source without *.dist-info metadata, so the lookup raises PackageNotFoundError and the view 500s. The same unguarded lookup existed in __init__.py, and cli.py carried a stale hard-coded "0.1.11" fallback.

Fix

Centralize one resilient resolver, rustfava._resolve_version, surfaced via the package __version__:

1. importlib.metadata.version (installed wheels)
2. setuptools_scm-generated _version.py (built artifacts)
3. "unknown" sentinel — never raises

application.py and cli.py now both consume rustfava.__version__, removing the duplicated logic and the stale literal. setuptools_scm is configured with version_file = "src/rustfava/_version.py" (gitignored) so built artifacts that lack dist-info still report the true version instead of unknown.

🤖 Generated with Claude Code

[robcohen]

Deep review — crash fix is solid; addressed the packaged-version gap (f5034e7).

The runtime fix is correct: no import cycle (cli.py's top-level from rustfava import __version__ runs after __init__ is fully initialized), click.version_option gets a plain str, the _version fallback path and broad except are justified ("never raise"), and existing test_version/test_help_pages still pass.

Gap the review caught: the version_file machinery was inert for the very build that motivated #191. The PyInstaller/.deb job runs no setuptools build, so _version.py was never generated and no dist-info was bundled → the frozen binary would report "unknown". The crash is fixed regardless, but the version display wasn't.

Fix (f5034e7): the PyInstaller spec now generates rustfava/_version.py at build time — from RUSTFAVA_VERSION (settable from the release tag) or setuptools_scm on a full checkout — and adds it to hiddenimports. Degrades gracefully to "unknown" when neither source is present (no regression).

Remaining one-liner follow-up: the release workflow should export RUSTFAVA_VERSION="${GITHUB_REF#refs/tags/v}" into the build-sidecar PyInstaller step so CI-built .deb/dmg binaries show the real version. I deferred that edit to avoid conflicting with the in-flight #197, which currently owns the build-sidecar region of desktop-release.yml — best landed right after #197 merges.

[robcohen]

Follow-up resolved: the RUSTFAVA_VERSION CI wiring is now in #197 (commit 2f4e65a), so once both PRs land the packaged binary reports the real version end-to-end. No further follow-up needed; either PR alone degrades gracefully to "unknown".

[robcohen]

Brought this up to date and fixed the CI failures — three layers:

1. Stale base: the branch predated the v0.19.0 saga; rebased onto current main, which cleared the test-job failures outright.
2. mypy: _resolve_version bound the name version twice (importlib's function, then _version.py's string) — runtime-correct but type-illegal. Renamed to metadata_version/scm_version; dropped a stale type: ignore.
3. Coverage gate: the fallback branches were untested (__init__.py at 63%), and separately the setuptools_scm-generated src/rustfava/_version.py (a side effect of this PR's version_file config) was being measured — a generated file's unexecuted branches failed the 100% gate. Added tests/test_version_resolution.py covering every branch (metadata / scm-file / sentinel / __getattr__) and omitted the generated file from coverage.

Local: 566 passed, coverage 100.00%, mypy clean, pinned ruff clean.