Repository navigation
fix(linux): keep AppImage library paths out of extension setup - #444
Merged
Merged
Conversation
The AppImage launcher points LD_LIBRARY_PATH (and possibly LD_PRELOAD and PATH) into its own mount. Extension setup inherited the raw environment, so Python, pip and the compilers it runs loaded the AppImage's bundled libraries, and in-app install/Repair failed where the same setup.py succeeded from a clean shell. Extension setup now runs with extensionChildEnv(): the Python/pip redirect stripping cleanPythonEnv() already did, plus removal of any path entry under APPDIR. It is a no-op outside an AppImage. The API and process extensions keep their environment, since they relaunch the bundled Electron binary. Refs #236
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes point 1 of #236: in-app extension install/Repair fails on the Linux AppImage while the identical
setup.pyrun from a clean shell (env -i) succeeds.The AppImage launcher points
LD_LIBRARY_PATH(and possiblyLD_PRELOADandPATH) into its mount (/tmp/.mount_Modly-XXXX).runExtensionSetupspawned the setup with the rawprocess.env, so Python, pip and the compilers it runs loaded the AppImage's bundled libraries.electron/main/child-env.ts, free of Electron imports so it is unit-tested directly:pythonChildEnv(env): the Python/pip redirect strippingcleanPythonEnv()already did (now delegates to it, behaviour unchanged).extensionChildEnv(env): the same, plus removal of every path entry underAPPDIR. No-op outside an AppImage, so Windows and macOS are unaffected.extensionChildEnv(process.env).Deliberately out of scope: the API (and the extension workers it spawns) and process extensions keep their environment. Both relaunch the Electron binary inside the mount (
MODLY_NODE_EXECUTABLE, for meshopt), which may need the AppImage's library paths.The other points of #236 are already addressed on
dev: venvs are built from the stablepython-embedcopy (point 2, since v0.4.3), andPOST /extensions/reloadstops extension workers (point 4). Point 3 (wheel tag matching) lives in the extensions' ownsetup.py.Refs #236
Test plan
child-env.test.mjs: mount entries dropped fromLD_LIBRARY_PATH/LD_PRELOAD/PATH, empty vars removed, look-alike sibling paths kept, no-op outside an AppImage, input not mutated,pythonChildEnvkeeps AppImage pathsnpm run test:node: 0 failures; ESLint clean; no newtscerrors