With the non-editable o3de install, the package lives in the per-user venv,
so manifest.get_this_engine_path() (which walks up from the package __file__)
resolved into the venv and engine.json wasn't found -> "Failed to get engine
info" / "Failed to initialize". O3DE has a built-in override for this
immutable-install case: when SNAP and SNAP_BUILD are set, get_this_engine_path
returns "$SNAP/$SNAP_BUILD". The wrapper now sets them to the engine root.
Verified by launching with these vars set: the Project Manager opens with no
engine.json errors.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Project Manager GUI does not set up O3DE's Python venv itself; it only
errors ("Missing python venv file .../pyvenv.cfg") when it's absent, which
cascades into "Failed to get engine info" / "Failed to initialize". Nothing
was running get_python.sh on launch.
The wrapper now runs python/get_python.sh when python.sh reports the venv is
missing/stale. get_python.sh downloads Python, creates the venv under the
writable ~/.o3de, and installs the o3de CLI from the prebuilt sdist. It is
idempotent and self-heals a half-built venv (venv creation uses --clear).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Repackage the official O3DE Linux .deb as a Flatpak and publish it as a
static OSTree repo on the 'pages' branch for install via flatpak remote.
- org.o3de.O3DE.yaml: flatpak-builder manifest (extracts the .deb into /app)
- o3de-wrapper.sh: launcher that locates the versioned o3de binary at runtime
- desktop + AppStream metadata under the app-id
- scripts/: live version resolver and local build helper
- .gitea/workflows/build-flatpak.yml: daily check -> build -> publish -> tag
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pc-heini