Add PyInstaller packaging and tufup-based auto-update pipeline

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 <noreply@anthropic.com>

1 files changed, 57 insertions, 0 deletions

diff --git a/scripts/release/repo_init.py b/scripts/release/repo_init.py
new file mode 100644
index 0000000..04c3579
--- /dev/null
+++ b/scripts/release/repo_init.py
@@ -0,0 +1,57 @@
+"""
+scripts/release/repo_init.py
+
+Run ONCE, ever, by the maintainer, locally. Generates the TUF signing keys
+and the initial repository metadata (including root.json, which later gets
+bundled into the app via labdaq.spec).
+
+Running this again after the repo already exists is safe (tufup skips
+re-creating keys/roles that already exist) but there is normally no reason
+to run it more than once per project.
+
+Keys land in ./keystore — never commit that directory (already gitignored).
+Back it up somewhere safe and private; losing the root key means you can
+never publish another trusted update to existing installs.
+"""
+
+import os
+from pathlib import Path
+
+from tufup.repo import Repository, RolesDict
+
+# Run from this script's own directory — tufup's config file (.tufup-repo-config)
+# and all repo_dir/keys_dir paths are resolved relative to the current working
+# directory, so invocation location must be consistent every time.
+os.chdir(Path(__file__).resolve().parent)
+
+APP_NAME = "labdaq"
+
+# tufup-example's 1-day timestamp / 7-day snapshot defaults assume an
+# automated CI worker re-signs on a schedule. We're signing manually
+# (see README.md in this directory), so use longer, human-manageable
+# expirations instead. Whichever of these lapses first is the cadence
+# you need to re-sign at, even between actual app releases.
+EXPIRATION_DAYS = RolesDict(root=365, targets=90, snapshot=90, timestamp=90)
+
+
+def main():
+    # Not using app_version_attr here: tufup's setuptools-based attribute
+    # reader resolves dotted paths relative to the current working directory,
+    # which we deliberately pin to this script's own directory below (tufup's
+    # own config-file/relative-path handling expects that) — the two
+    # assumptions conflict. repo_release.py passes the version explicitly
+    # instead, which sidesteps this entirely.
+    repo = Repository(
+        app_name=APP_NAME,
+        repo_dir=Path("repository"),
+        keys_dir=Path("keystore"),
+        expiration_days=EXPIRATION_DAYS,
+    )
+    repo.initialize()
+    repo.save_config()
+    print(f"Initialized tufup repo for '{APP_NAME}' in ./repository, keys in ./keystore")
+    print("Back up ./keystore now, somewhere private and durable. It is gitignored on purpose.")
+
+
+if __name__ == "__main__":
+    main()