From bfbdd0c19910f464e779fa64cc0ec8590f8e37c1 Mon Sep 17 00:00:00 2001 From: Christian Kolset Date: Fri, 31 Jul 2026 15:52:28 -0600 Subject: Add PyInstaller packaging and tufup-based auto-update pipeline MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Full pipeline, verified end-to-end against the real installed tufup 0.10.0 API (initial docs/summaries turned out inaccurate in places — e.g. the apply method is download_and_apply_update, not update; confirmed by inspecting installed package source directly rather than trusting docs alone): - core/version.py: single-source app version constant. - labdaq.spec: PyInstaller onedir build (must be onedir, not onefile — tufup replaces individual files in the install dir on update). Bundles ui/*.qss, plugins/ (needed for runtime plugin discovery), and repository/metadata/root.json once repo_init.py has produced one. Built and smoke-tested: the frozen exe launches and stays running. - scripts/release/{repo_init,repo_release}.py: maintainer-run release tooling using tufup.repo.Repository, manual local signing (keys never touch CI). Both actually run end-to-end during development of this feature against a real build, not just written and assumed correct. Longer expiration_days than tufup-example's CI-oriented defaults (targets/snapshot/timestamp 90d instead of 7d/7d/1d), since we're signing manually, not on an automated daily schedule — see scripts/release/README.md for the re-signing cadence this still requires even between releases. - core/updater.py: thin Client wrapper. Refuses to run outside a frozen build (getattr(sys, "frozen", False)) since there's no installed bundle for tufup to update in `python main.py` dev mode. Bootstraps the bundled root.json into the metadata cache dir on first run — tuf.ngclient.Updater loads root.json from local disk on construction, it does not fetch it remotely by design (the root of trust can't come from the same server being verified). - core/app_settings.py: factored out app_data_dir() (was inline in _settings_path()) so the updater's metadata/target cache dirs live in the same per-user location as settings.json, deliberately outside the install directory an update can replace/move. - Settings > General: version display + "Check for Updates" button, manual-only per discussion (no silent background network calls or surprise restarts for a lab-instrument-control app). Metadata/targets are hosted on this repo's "updates" GitHub Release — a fixed tag, not a normal per-version tag, because TUF's top-level metadata needs a stable URL across app versions. No such GitHub-Releases- hosting example exists in tufup or tufup-example; verified this by fetching tufup-example's actual GitHub Actions workflow file directly after a web search wrongly suggested one existed — the design here is ours, not copied from upstream. Not yet done, deliberately left for the user: running repo_init.py for real (generates production signing keys), and creating the actual "updates" GitHub Release. Both are irreversible-ish, security-sensitive, externally-visible actions outside what should happen without the user directly driving them. Co-Authored-By: Claude Sonnet 5 --- scripts/release/repo_release.py | 64 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 scripts/release/repo_release.py (limited to 'scripts/release/repo_release.py') diff --git a/scripts/release/repo_release.py b/scripts/release/repo_release.py new file mode 100644 index 0000000..a3c8d03 --- /dev/null +++ b/scripts/release/repo_release.py @@ -0,0 +1,64 @@ +""" +scripts/release/repo_release.py + +Run after every `pyinstaller labdaq.spec` build, from anywhere (paths are +made absolute below before the working directory changes). Packages the +freshly built dist/LabDAQ bundle as a new signed tufup target. + +Prerequisites: + - repo_init.py has been run once already (./repository and ./keystore exist) + - core/version.py has been bumped to the new version + - dist/LabDAQ/ exists (pyinstaller labdaq.spec has just been run) + +After this completes, see README.md in this directory for how to publish +the updated ./repository/metadata and ./repository/targets files to the +"updates" GitHub Release. +""" + +import os +import sys +from pathlib import Path + +_THIS_DIR = Path(__file__).resolve().parent +_REPO_ROOT = _THIS_DIR.parent.parent +_DIST_DIR = _REPO_ROOT / "dist" / "LabDAQ" + +# Import core.version before changing cwd — needs the repo root on sys.path, +# which won't be true anymore once we chdir into scripts/release below. +sys.path.insert(0, str(_REPO_ROOT)) +from core.version import __version__ as APP_VERSION + +from tufup.repo import Repository + +# tufup's config file / relative repo_dir / keys_dir all resolve against cwd +# (same reasoning as repo_init.py) — pin it here too, for the same reason. +os.chdir(_THIS_DIR) + + +def main(): + if not _DIST_DIR.is_dir(): + raise SystemExit( + f"{_DIST_DIR} not found — run `pyinstaller labdaq.spec` from the " + f"repo root first." + ) + + repo = Repository.from_config() + + changelog = input(f"One-line changelog for v{APP_VERSION} (optional): ").strip() + custom_metadata = {"changelog": changelog} if changelog else None + + repo.add_bundle( + new_bundle_dir=_DIST_DIR, + new_version=APP_VERSION, + skip_patch=True, # no binary delta patching for now — full archive only + custom_metadata=custom_metadata, + ) + repo.publish_changes(private_key_dirs=[Path("keystore")]) + + print(f"Signed and published v{APP_VERSION} to ./repository") + print("Next: upload ./repository/metadata/* and ./repository/targets/* " + "to the 'updates' GitHub Release — see README.md in this directory.") + + +if __name__ == "__main__": + main() -- cgit v1.2.3