Pick a Windows release route

Scope

This is printable page copy and rule documentation for choosing a Windows 11 x64 route for a Python GUI app. It is not selector code. It documents the locally reproduced route and labels every other route as external or not reproduced.

Questions

1. Framework: Is the app pywebview on the PySide6 Qt backend, a direct native PySide6 app, or another framework?
2. Frozen form: Is the current build --onedir, --onefile, both, or not yet frozen?
3. Dependency licensing: Do dependency licenses require end users to replace or relink bundled libraries? If yes, select the mapped --onedir route for that requirement. The canonical SXT policy permits either layout for MIT/open-source tools, but the actual dependency obligations and release behavior still require review and testing.
4. Desired delivery: Is the goal a website download, Microsoft Store, both, or undecided? A WinGet goal is captured separately because it is an overlay.
5. Installer state: Is the current distributable none, a portable archive, EXE, MSI, or MSIX? If it is an installer, does it have a stable identity?
6. Update owner: Will updates be owned by the Store, the application, the installer, manual download, or is that undecided? In the reproduced app estate, the app only notifies about GitHub releases. It does not self-update.
7. Install needs: Do you need a Start menu entry, optional desktop shortcut, optional launch after setup, Add or Remove Programs uninstall, per-user installation, or an all-users option?
8. Signing position and geography: Will artifacts be unsigned, Authenticode-signed, or submitted through a Store route? Where is the developer or organization eligible to use the chosen signing service or certificate?
9. Stable versioned HTTPS hosting: Can you host each installer at a stable, versioned HTTPS URL for as long as an external catalog or Store installer route needs it?
10. WinGet goal: Is WinGet only a discovery and command-line installation overlay for a released installer, or are you expecting it to replace the installer, hosting, signing, update, commerce, or external review responsibilities?

Deterministic result structure

Viable routes in the mapped evidence

Eliminated routes for this draft set

Viable but not reproduced here

Store or MSIX distribution, Authenticode signing, direct native PySide6 packaging, and --onefile may be viable but are not reproduced here. The canonical SXT policy permits either PyInstaller layout for MIT/open-source tools. Other license and distribution models require their own analysis and testing.

WinGet is an overlay

WinGet can add discovery and command-line installation for an already released installer. It does not create the installer, host its asset, sign it, update the application, handle commerce, or decide repository acceptance.

Artifact chain

source at a release tag -> --onedir folder when LGPL replaceability is required -> Windows build runner -> complete folder -> portable ZIP and Inno Setup installer -> SHA-256 file and GitHub build provenance -> GitHub Release -> optional WinGet manifest pointing to a released installer

Ownership table

Production evidence and mapped evidence

The Build-Tools workflow builds from a tag, produces ZIP and installer artifacts, writes SHA-256 files, and creates provenance attestations. Simple UNA Log Viewer’s build script supplies the --onedir, PySide6, qtpy, and truststore build pattern. Its initial WinGet submission and update are limited to that application’s accepted lifecycle.

Unknowns and prerequisites

• A signing route needs an eligible signer, certificate or service choice, geography review, signing operation, and artifact validation.
• An MSI or EXE Store route needs the Store’s current requirements, a signed installer, stable versioned HTTPS hosting, account operation, and external review.
• MSIX needs package preparation, Store or direct-distribution prerequisites, and separate testing.
• A WinGet submission needs a released installer URL, matching version and hash data, repository validation, and external review.
• A --onefile or direct native PySide6 route needs its own application and artifact testing.

Printable text summary

For the estate’s PolyForm Noncommercial/Internal Use builds, the mapped route is PyInstaller --onedir, a portable ZIP, and the shared Inno Setup installer because bundled LGPL libraries must remain replaceable by end users. This does not say --onedir is generally better or that --onefile universally violates LGPL. The app can notify about a GitHub release but does not self-update. Hashes verify bytes and GitHub provenance identifies the build origin. WinGet is an optional discovery overlay, not an installer, hosting, signing, update, commerce, or review system.

Unsupported or external outcomes

• No result here establishes malware safety or SmartScreen reputation.
• Store or MSIX remains deferred and not reproduced.
• General WinGet acceptance is external.
• The released local artifacts are not Authenticode-signed.
• This is not legal advice. Layout alone does not fulfill all license obligations; notices, source or offer requirements, and the actual dependency and license versions still matter.

Related drafts

• Release route hub
• One-file versus one-folder
• Windows installer
• Code-signing facts

Source ledger