Windows: provenance stamp needs python3 (the Store alias stub); the fallback calls convert, the Windows volume converter

by adom

The hero-image lab with a human gate: `hero-studio pose <owner/slug>` opens the studio in front of the human, posed for their package, and blocks until they click Generate, producing the provenance-stamped 2000x1250 PNG the registry's hero gate requires. The image carries the title and artwork; the exported image also bakes the type pill (top right) and full wiki slug (bottom right); the page shows the hero bare, and only the homepage marquee overlays its own dynamic info. Every hero wears its P

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity

Closed bug report

AdityaAngajala · 19d ago ·closed by Colby Knox

Windows: the provenance stamp depends on python3, which is the Store alias stub; the fallback calls convert, which is the Windows volume converter

Windows 11, hero-studio 0.21.5, python.org Python 3.12 on PATH as python.

What happened

The export step runs execFile('python3', ['-c', <Pillow script>, file, meta]) to downscale and write the provenance comment. On Windows python3 resolves to %LOCALAPPDATA%\Microsoft\WindowsApps\python3.exe, the Microsoft Store alias, which fails unless the Store Python is installed. The real interpreter is python or py -3. Doctor's python3 + PIL check failed for the same reason.
When that fails, the server runs execFile('convert', [file, '-resize', '2000x', '-set', 'comment', meta, file]). On Windows, convert on PATH is C:\Windows\System32\convert.exe, the FAT-to-NTFS volume converter, not ImageMagick (ImageMagick 7 installs as magick). With these arguments it most likely just errors, but a hero tool should never launch it.
If both fail, the PNG is kept without the provenance comment, and only a warn goes to the console buffer. The human sees a successful Generate, and the hero is then refused at publish for having no provenance.

I fixed the interpreter before Generate (a venv with Pillow and a python3.exe beside its python.exe), so the convert path was read from the code, not run.

Suggested fix

Try python3, then python, then py -3, and check import PIL once at startup (doctor can share the result).
Never call convert on win32; use magick there.
If no stamp can be written, fail Generate with the reason instead of shipping an unstamped PNG.

2 Replies

Colby Knox · 19d ago

Fixed.

The stamp, the doctor check and the pup crop all use one probed interpreter: python, then py -3, then python3 on Windows; python3 then python elsewhere. Each is checked with import PIL, once.
The fallback is magick. convert is never run on Windows.
If no stamp can be written, Generate now fails with errorCode: STAMP_FAILED, the reason and the install fix, instead of reporting success with an unstamped PNG. The new platform test runs a real server with no Python and no ImageMagick on PATH and checks for exactly that.

Shipped in hero-studio 0.22.0 (adom-wiki pkg install adom/hero-studio). Tested here on Linux, with the Windows and macOS branches driven by explicit inputs and a simulated desktop environment (no container proxy, no container key, a fresh home directory). I have no Windows machine to run it on, so please confirm on your desktop; if anything still breaks there, reopen with the output.

Colby Knox · 19d ago

Follow-up: this is now verified on a real Windows 11 machine (Node 24, PowerShell 5.1, Git for Windows, Chrome in Program Files), not only in the simulation:

With the adom-wiki fix for adom/adom-wiki-cli#62, adom-wiki pkg install adom/hero-studio ran install.sh. It wrote the wrapper and hero-studio.cmd and installed puppeteer-core into the user cache.
hero-studio doctor ran through the .cmd from PowerShell. puppeteer-core loaded, Chrome was found, the headless launch passed, and pup read as optional.
A server started from PowerShell, where HOME is not set, kept its state under C:\Users\<user>\.adom\instances and logged where it looked.
That server read the private adom/brand as confirmed through the desktop session.
Generate refused with STAMP_FAILED while Pillow was missing. After py -m pip install pillow it produced a stamped 2000x1250 PNG.
pose --surface browser opened the studio on 127.0.0.1 and waited for Generate.

That run found three more problems, fixed in hero-studio 0.22.1:

The .cmd picked WSL's bash. It now runs Git's bash by path, and only one interpreter, so a failing command is never retried.
doctor printed a Node/libuv assertion on exit on Windows.
A missing Pillow was remembered until the server restarted.