Environment: Ubuntu (kernel 7.0), RTX 5090 (Blackwell sm_120), NVIDIA driver w/ CUDA 13.3 userland, Modly AppImage v0.4.x, embedded Python 3.11.9, data dir relocated to a large secondary disk. Found while driving Modly headlessly (REST + MCP) for a game-asset pipeline.
Four related problems in the Linux extension setup / venv lifecycle. Together they made every extension repair fail or silently rot until repaired by hand.
1. In-app Repair/Setup fails (AppImage env leak)
Running an extension setup from inside the app fails during venv creation, while the identical setup.py invocation over SSH with a clean env (env -i) succeeds. The AppImage process environment (LD_LIBRARY_PATH pointing into the mount) poisons the child pip/venv processes.
Suggested fix: launch setup subprocesses with a sanitized environment.
2. Venvs are created on the ephemeral AppImage mount
pyvenv.cfg of freshly repaired venvs contains home = /tmp/.mount_Modly-XXXX/.... That mount path changes every launch, so every extension venv dies on the next app restart. Rebuilding on the persistent embedded runtime (~/.config/Modly/python-embed/bin/python3.11) survives restarts.
Suggested fix: always create venvs from the persistent python-embed path, never sys.executable inside the mount.
3. Wheel matcher misses local-version tags
The setup wheel matcher failed to match wheels tagged +cu128torch2.7 (it appears to normalize to torch27 and then not match), so cumesh/flex_gemm/spconv silently did not install and the extension failed at runtime instead of at setup.
Suggested fix: compare parsed PEP 440 local versions instead of string fragments, and fail setup loudly when a required wheel resolves to nothing.
4. POST /extensions/reload does not restart workers
Extension workers persist across runs (by design), but reload does not recycle them, so repaired venvs / patched site-packages keep serving stale in-memory state. Every fix above required a manual pkill of the worker to take effect.
Suggested fix: terminate extension workers on reload and after setup/repair.
Minor, same area
hunyuan3d texgen differentiable_renderer/setup.py inherits a baked build prefix from the embedded Python's sysconfig (-I/install/include/python3.11), so source builds cannot find Python.h without manual CFLAGS.- Texgen setup picks
clang on systems that only have gcc.
Environment: Ubuntu (kernel 7.0), RTX 5090 (Blackwell sm_120), NVIDIA driver w/ CUDA 13.3 userland, Modly AppImage v0.4.x, embedded Python 3.11.9, data dir relocated to a large secondary disk. Found while driving Modly headlessly (REST + MCP) for a game-asset pipeline.
Four related problems in the Linux extension setup / venv lifecycle. Together they made every extension repair fail or silently rot until repaired by hand.
1. In-app Repair/Setup fails (AppImage env leak)
Running an extension setup from inside the app fails during venv creation, while the identical
setup.pyinvocation over SSH with a clean env (env -i) succeeds. The AppImage process environment (LD_LIBRARY_PATHpointing into the mount) poisons the child pip/venv processes.Suggested fix: launch setup subprocesses with a sanitized environment.
2. Venvs are created on the ephemeral AppImage mount
pyvenv.cfgof freshly repaired venvs containshome = /tmp/.mount_Modly-XXXX/.... That mount path changes every launch, so every extension venv dies on the next app restart. Rebuilding on the persistent embedded runtime (~/.config/Modly/python-embed/bin/python3.11) survives restarts.Suggested fix: always create venvs from the persistent python-embed path, never
sys.executableinside the mount.3. Wheel matcher misses local-version tags
The setup wheel matcher failed to match wheels tagged
+cu128torch2.7(it appears to normalize totorch27and then not match), so cumesh/flex_gemm/spconv silently did not install and the extension failed at runtime instead of at setup.Suggested fix: compare parsed PEP 440 local versions instead of string fragments, and fail setup loudly when a required wheel resolves to nothing.
4.
POST /extensions/reloaddoes not restart workersExtension workers persist across runs (by design), but reload does not recycle them, so repaired venvs / patched site-packages keep serving stale in-memory state. Every fix above required a manual
pkillof the worker to take effect.Suggested fix: terminate extension workers on reload and after setup/repair.
Minor, same area
hunyuan3dtexgendifferentiable_renderer/setup.pyinherits a baked build prefix from the embedded Python's sysconfig (-I/install/include/python3.11), so source builds cannot findPython.hwithout manualCFLAGS.clangon systems that only have gcc.