Symlink pointing to a temporary mounting point

[CodeSkink]

I kept installing Modly on my Linux Mint 22.3 system and it would not restart after shutting it down. After multiple tries I asked Claude AI.

Below is part of the answer Claude AI gave:

There's the problem.

The symlink points to: /tmp/.mount_Modly-6nLBBJ/resources/python-embed/bin/python3

That's inside the AppImage's temporary mount point.

When the AppImage is running, it mounts itself to /tmp/.mount_Modly-XXXXXX/ — but that mount point gets a random suffix every launch.

So the symlink is hardcoded to 6nLBBJ but next time it mounts as 7xKPQR or something else, and the symlink instantly breaks.

This is a bug in Modly — it's bundling its own Python and creating venv symlinks pointing to the ephemeral mount path instead of a stable location.

The workaround is ugly but reliable until Modly fixes the bug. I'd also recommend reporting it to them — the embedded Python venv symlink should point to a stable path, not an ephemeral

[DrHepa]

Hi, I think this is a real AppImage-specific setup issue.
On packaged Linux builds, Modly currently creates the persistent Python venv using the bundled Python runtime from process.resourcesPath/python-embed.
Inside an AppImage, that path can resolve to something like:
/tmp/.mount_Modly-XXXXXX/resources/python-embed/bin/python3

The problem is that /tmp/.mount_Modly-XXXXXX is an ephemeral AppImage mount path and changes between launches. If the created venv contains symlinks back to that mounted Python runtime, the venv becomes invalid after restarting the AppImage.

The robust fix would be to avoid creating a persistent venv directly from the AppImage-mounted Python path. Instead, on packaged Linux/AppImage builds, Modly should first copy or extract the bundled Python runtime to a stable user-owned location, for example:
/dependencies/python-embed/
Then setup should create the venv from that stable Python path:
/dependencies/python-embed/bin/python3 -m venv /venv
instead of creating it from:
/tmp/.mount_Modly-XXXXXX/resources/python-embed/bin/python3
A possible implementation direction would be:
if (process.platform === 'linux' && app.isPackaged) {
const pythonExe = await ensureStablePackagedPython(userData)
await createVenv(pythonExe, venvDir, win)
}
Where ensureStablePackagedPython() copies process.resourcesPath/python-embed into a stable dependencies directory if it is missing or outdated, and returns the stable bin/python3 path.

As a temporary workaround, running Modly from source with:
bash launch.sh
should avoid this specific AppImage issue, because the non-packaged Linux flow uses the system Python to create the venv instead of the AppImage-mounted bundled Python. This does not fix the packaged AppImage build, but it can help users continue working until the AppImage setup path is fixed.