Skip to content

feat: show the running build under Help > About qtxterm - #9

Open
rigidlab wants to merge 3 commits into
mainfrom
feat/help-about-version
Open

rigidlab wants to merge 3 commits into
mainfrom
feat/help-about-version

Conversation

@rigidlab

Copy link
Copy Markdown
Owner

Adds Help > About qtxterm, showing which build is running - including for development checkouts that are nowhere near a release.

Why

There is no usable version string today. pyproject.toml carries a static 1.0.0 that only moves on a release, so every commit between two releases reports the same thing, and src/qtxterm/__init__.py has no __version__ at all. An editable install sharpens the problem: the code is read live from a checkout, so the reported version stays fixed while the code underneath changes with every branch switch.

What it shows

Development checkout:

qtxterm 1.0.0
v1.0.0-24-g01d500c
commit    2026-09-25 07:13:13 -0700
source    C:\Users\phuta\git\qtxterm

Installed wheel, where there is no .git to ask:

qtxterm 1.0.0
installed 2026-09-20 15:05

The describe string carries -dirty when the checkout has uncommitted changes, which is the case that a commit hash alone would misreport.

Design

version_info.py holds no Qt, so the string is testable without a widget. Git is consulted only when REPO_ROOT/.git exists, with a 2s timeout - the About dialog is not worth hanging the UI for. All three real-world failures degrade to the packaged metadata rather than raising:

  • no git on PATH -> FileNotFoundError
  • no repository -> non-zero exit
  • busy repo -> TimeoutExpired

build_info() is cached; the answer cannot change mid-process.

The dialog keeps the text selectable and monospaced, since version_lines() aligns its labels in columns that a proportional font would undo, and a Copy button puts the block on the clipboard for pasting into a bug report.

Tests

13 new tests. The fallback paths get the most attention, since they are what runs on an installed copy where nobody is watching. Full suite: 519 passed, 1 skipped.

🤖 Generated with Claude Code

rigidlab and others added 3 commits September 25, 2026 07:13
The packaged version cannot answer "which build is this?" - pyproject
carries a static version that only moves on a release, so every commit
between two releases reports the same string. An editable install makes
it worse: the code is read live from a checkout, so the version stays
fixed while the code underneath changes with every branch switch.

Ask git when there is a checkout to ask, and fall back to the packaged
metadata and install time when there is not - a wheel has no .git, and a
user machine may have no git. Both the missing-binary and timeout paths
degrade rather than raise, so identifying a build can never be what
breaks the app.

Code assisted by Opus 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds a second Help entry opening a small dialog with the logo, the
version block and a Copy button, so the answer to "which build are you
on?" can be pasted into a bug report rather than retyped.

The text is selectable and monospaced: version_info aligns its labels in
columns, which a proportional font would undo.

Code assisted by Opus 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The fallback paths matter more than the happy one - they are what runs
on an installed copy, which is where nobody is watching. Missing git
binary, non-zero exit outside a repository, and a timeout are each
covered, as is the dialog surviving a missing logo asset.

Code assisted by Opus 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant