What a discontinued app leaves behind

Most of what you write for a product that does not ship is worth nothing to anyone else, because it only ever made sense inside that product; the feature code encodes decisions about a problem nobody else has. The exception is the infrastructure you had to get right before you could write a single feature, and in CommandLane's case that was running Python inside a desktop app. I spent weeks on it. Anyone building the same shape of thing spends the same weeks, so I pulled it out and published it.

It is at github.com/matshoppenbrouwers/tauri-python-sidecar, MIT licensed: a Tauri v2 app that runs Python as a supervised child process rather than embedding an interpreter in the binary. The supervisor restarts the child on a capped backoff ladder and resets its failure count after five minutes of health. The two talk over a local TCP connection authenticated with a token the Python side generates at startup and writes to a file created at mode 0600, compared on every call with hmac.compare_digest; the renderer can reach only an explicit allowlist of methods. Around that sits the rest of what a real app needs and a tutorial never covers: SQLite migrations behind a cross-process lock, write-ahead-log recovery gated on a health check, PID lock files and a stale-worker sweep, Nuitka packaging, installer hooks that kill escaped children, and a signed updater. The demo is one window with a status badge; you kill the Python process yourself and watch the supervisor bring it back.

The part I would defend hardest is that the annotated comments are the product. Every constant in there is a scar, and I kept the explanations attached to them rather than cleaning them off for presentation. Excluding the machine-learning libraries from Nuitka's import graph took build memory from 14 GB to 2 GB. Nuitka's no_annotations optimisation silently breaks Pydantic v2, which reads those annotations at runtime. The --show-progress flag crashes the build outright. A tidy version of this repository with the reasons stripped out would be worse than nothing to clone, because it would look authoritative while telling you only what the code does, which you could already read.

Preparing it for strangers is also what surfaced a real bug. On startup the app cleaned up after a previous crash by reading a process ID from a stale lock file and killing whatever held it, with no check that the process was actually ours. Operating systems reuse process IDs as soon as they are free, so on a later launch that number can belong to anything at all, and the cleanup would have terminated an unrelated program. It had been sitting in the private app for months and I had never looked at it closely, because nothing had gone visibly wrong. Both sides now record the worker's image name in the lock file and refuse to kill a process they cannot prove they own.

The same pass forced out a fix I had been sitting on for two months. On Windows, cargo test in a Tauri project can die in the loader before a single test runs, with STATUS_ENTRYPOINT_NOT_FOUND and no test name printed, because the test binary gets no application manifest and therefore binds against the old system copy of a Windows library that lacks one exported function. The fix is a cargo runner that patches the manifest into test binaries only when one is missing. It was written down nowhere, in a thread where people were still working around it one at a time, so it is now a comment on the open Tauri issue as well as a file in the repository.

I should bound this. I do not know that anyone will clone it, and a template with no users is just a repository with good comments; the honest claim is that the work existed either way and publishing it cost me two days on top. What I did not expect was that preparing code for people I will never meet is a better review than any I would have run on it privately.