Add Dockerfile.alpasim with a baked-in virtual environment

[jatentaki]

As noted in this alpasim issue, our omnidreams-alpasim integration release was missing the Dockerfile.alpasim file needed for building the alpasim-compatible image.

This MR:

• Adds the missing file, which generates python wheels in a temporary container and copies them into a minimal runtime image.
• Fixes a missing declaration in integrations/omnidreams/ludus-renderer/pyproject.toml, which caused built wheels to not work out-of-tree.
• Is not a full resolution to the user-reported issue as there is a minor adjustment + a dataset fixup left on Alpasim side.

[greptile-apps]

Greptile Summary

This PR adds the missing Dockerfile.alpasim for building an alpasim-compatible image using a multi-stage build, and fixes the ludus-renderer wheel packaging to include previously excluded .inl header files in the framework subdirectory.

• New Dockerfile.alpasim: Uses FLASHDREAMS_BASE_IMAGE as both the build and runtime base. The builder stage installs flashdreams-omnidreams (and its workspace dependencies) non-editably into a versioned venv at /opt/flashdreams, which is then copied verbatim into the runtime image with the absolute path preserved so shebang lines and linker paths remain valid.
• pyproject.toml fix: Adds _cpp/cudaraster/framework/**/*.inl to [tool.setuptools.package-data], completing the set of C++ source glob patterns for the framework subdirectory. Without this, JIT-compiled extension builds from an installed wheel would fail to locate inline definitions.

Confidence Score: 5/5

Safe to merge — both changes are well-scoped additions with no correctness regressions.

The Dockerfile follows a sensible multi-stage pattern, keeps the venv at a fixed absolute path to avoid broken shebangs, and correctly uses --locked and --no-editable. The pyproject.toml change is a targeted one-line addition that completes an existing glob family. The only open item (dev-dependency bloat via uv sync without --no-group) was already surfaced in a prior review thread and is a size concern, not a correctness issue.

No files require special attention.

Important Files Changed

Filename	Overview
docker/Dockerfile.alpasim	New multi-stage Dockerfile that builds a venv with non-editable wheels and copies it into the runtime image; structure is sound, though uv sync without --no-dev/--no-group (already noted in a previous thread) is the main open concern.
integrations/omnidreams/ludus-renderer/pyproject.toml	Adds the missing _cpp/cudaraster/framework/**/*.inl glob to package-data, completing the existing hpp/cpp/h pattern set and fixing out-of-tree wheel installs that need these inline headers for JIT compilation.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Docker as Docker Build
    participant Builder as wheel-builder stage (FLASHDREAMS_BASE_IMAGE)
    participant UvCache as uv cache (/root/.cache/uv)
    participant Venv as /opt/flashdreams venv
    participant Runtime as Runtime stage (FLASHDREAMS_BASE_IMAGE)

    Docker->>Builder: FROM flashdreams:local AS wheel-builder
    Docker->>Builder: COPY pyproject.toml uv.lock + sources
    Builder->>Builder: "ENV UV_PROJECT_ENVIRONMENT=/opt/flashdreams"
    Builder->>UvCache: mount cache
    Builder->>Venv: uv sync --locked --package flashdreams-omnidreams --no-editable
    Note over Venv: Builds ludus-renderer wheel (includes .inl files from fix) + flashdreams-omnidreams wheel into /opt/flashdreams
    Docker->>Runtime: FROM flashdreams:local (runtime stage)
    Runtime->>Venv: "COPY --from=wheel-builder /opt/flashdreams /opt/flashdreams"
    Runtime->>Runtime: "ENV VIRTUAL_ENV=/opt/flashdreams"
    Runtime->>Runtime: "ENV PATH=${VIRTUAL_ENV}/bin:${PATH}"
    Runtime->>Runtime: WORKDIR /app

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Docker as Docker Build
    participant Builder as wheel-builder stage (FLASHDREAMS_BASE_IMAGE)
    participant UvCache as uv cache (/root/.cache/uv)
    participant Venv as /opt/flashdreams venv
    participant Runtime as Runtime stage (FLASHDREAMS_BASE_IMAGE)

    Docker->>Builder: FROM flashdreams:local AS wheel-builder
    Docker->>Builder: COPY pyproject.toml uv.lock + sources
    Builder->>Builder: "ENV UV_PROJECT_ENVIRONMENT=/opt/flashdreams"
    Builder->>UvCache: mount cache
    Builder->>Venv: uv sync --locked --package flashdreams-omnidreams --no-editable
    Note over Venv: Builds ludus-renderer wheel (includes .inl files from fix) + flashdreams-omnidreams wheel into /opt/flashdreams
    Docker->>Runtime: FROM flashdreams:local (runtime stage)
    Runtime->>Venv: "COPY --from=wheel-builder /opt/flashdreams /opt/flashdreams"
    Runtime->>Runtime: "ENV VIRTUAL_ENV=/opt/flashdreams"
    Runtime->>Runtime: "ENV PATH=${VIRTUAL_ENV}/bin:${PATH}"
    Runtime->>Runtime: WORKDIR /app

Loading

_{Reviews (2): Last reviewed commit: "Add Dockerfile.alpasim with a baked-in v..." | Re-trigger Greptile}

[jarcherNV]

This change looks reasonable to me.

One small issue before merge: docker/Dockerfile.alpasim defaults to FLASHDREAMS_BASE_IMAGE=flashdreams-base:local, but the existing Docker docs build the base image as flashdreams:local:

docker build -t flashdreams:local -f docker/Dockerfile .

Do these need to match? If they do, we should either change the name or update the doc I think.

[jatentaki]

This change looks reasonable to me.

One small issue before merge: docker/Dockerfile.alpasim defaults to FLASHDREAMS_BASE_IMAGE=flashdreams-base:local, but the existing Docker docs build the base image as flashdreams:local:

docker build -t flashdreams:local -f docker/Dockerfile .

Do these need to match? If they do, we should either change the name or update the doc I think.

@jarcherNV Good point, aligned. This will require a matching change in alpasim but I need to fix that up anyway so I used flashdreams:local in here.

[jarcherNV]

LGTM