Rebuilding wipes the user config (dist/ is both install dir and config dir) #3

New issue

Open

opened 2026-08-15 12:28:29 +02:00 by Grovy311 · 0 comments

Grovy311 commented

2026-08-15 12:28:29 +02:00

Collaborator

On dev/jappel, versapad_data.app_dir() returns the install directory when frozen:

if getattr(sys, "frozen", False):
    return os.path.dirname(sys.executable)

and build_and_deploy.ps1 deploys to $projectDir\dist\VersaPadViewer, clearing it first:

if (Test-Path $localDir) { Remove-Item $localDir -Recurse -Force }
Copy-Item "$buildSrc\dist\VersaPadViewer" -Destination $localDir -Recurse

So the config file lives in the exact directory the build script deletes on every run.
Each rebuild silently discards versapad_config_all.json.

What makes it hard to notice: load_or_fetch() no longer errors on a missing file, it
recreates one — from the board if reachable, otherwise default_combined(). The board
has no storage for the local-only fields, so the regenerated config looks completely
normal (bindings, LEDs, macros all correct) while profile_names — and any other
local-only data — are silently gone. If no board is attached you get an empty config
instead. Nothing in the UI indicates that anything was lost.

I hit this downstream after cherry-picking the commit: I rebuilt ~8 times during a UI
session and kept losing local-only data I had just entered, re-entering it each time
without realising the next build would drop it again.

Fix I went with, in case it's useful: keep program and user data apart — config in
%APPDATA%\<App> (roaming), install dir untouched by it — plus a defensive step in the
build script that rescues any versapad_config*.json found in the target across the
deploy, so existing installs survive the change.

Two smaller things worth considering alongside:

app_dir() branching on sys.frozen makes the built exe and a source/MCP run read
different files; mine drifted apart until I noticed the exe showing a different
profile than the MCP server reported.
A self-healing path that silently produces plausible data can mask data loss — it may
be worth logging or surfacing when it kicks in.

On `dev/jappel`, `versapad_data.app_dir()` returns the install directory when frozen: if getattr(sys, "frozen", False): return os.path.dirname(sys.executable) and `build_and_deploy.ps1` deploys to `$projectDir\dist\VersaPadViewer`, clearing it first: if (Test-Path $localDir) { Remove-Item $localDir -Recurse -Force } Copy-Item "$buildSrc\dist\VersaPadViewer" -Destination $localDir -Recurse So the config file lives in the exact directory the build script deletes on every run. Each rebuild silently discards `versapad_config_all.json`. What makes it hard to notice: `load_or_fetch()` no longer errors on a missing file, it recreates one — from the board if reachable, otherwise `default_combined()`. The board has no storage for the local-only fields, so the regenerated config looks completely normal (bindings, LEDs, macros all correct) while `profile_names` — and any other local-only data — are silently gone. If no board is attached you get an empty config instead. Nothing in the UI indicates that anything was lost. I hit this downstream after cherry-picking the commit: I rebuilt ~8 times during a UI session and kept losing local-only data I had just entered, re-entering it each time without realising the next build would drop it again. Fix I went with, in case it's useful: keep program and user data apart — config in `%APPDATA%\<App>` (roaming), install dir untouched by it — plus a defensive step in the build script that rescues any `versapad_config*.json` found in the target across the deploy, so existing installs survive the change. Two smaller things worth considering alongside: - `app_dir()` branching on `sys.frozen` makes the built exe and a source/MCP run read different files; mine drifted apart until I noticed the exe showing a different profile than the MCP server reported. - A self-healing path that silently produces plausible data can mask data loss — it may be worth logging or surfacing when it kicks in.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: jappel/VersaGUI-py#3

No description provided.

Rows
Columns