Skip to content

mcpp new --template imgui fails on all platforms: package 'imgui@1.92.8' has no mcpp.toml #265

Description

@Sunrisepeak

Summary

mcpp new <name> --template imgui fails on all three platforms in the
post-release / scheduled ci-fresh-install workflow:

 Downloading compat.imgui v1.92.8
error: package 'imgui@1.92.8' has no mcpp.toml

The step is Template: mcpp new --template imgui (fetch path), and it fails
identically on Linux fresh install, macOS fresh install and
Windows fresh install.

Not a 0.0.102 regression

Found while verifying the 0.0.102 release, but it predates it. The error text
is byte-identical in the scheduled run that executed before the 0.0.102
batch landed:

run date mcpp result
29736516661 2026-07-20 0.0.101 release all jobs green
29814932554 2026-07-21 08:36 scheduled error: package 'imgui@1.92.8' has no mcpp.toml
29873685262 2026-07-21 22:30 0.0.102 release same error, same package, same version

So the regression window is between 2026-07-20 and 2026-07-21 — after
0.0.101's post-release verification passed and before the July 21 schedule.
Nothing in mcpp released in that window, which points at the package/index
side (compat.imgui 1.92.8 or the template's fetch path) rather than at the
engine.

Where to look

  • compat.imgui at 1.92.8: does the payload actually carry an mcpp.toml,
    or is it expected to be synthesized from the descriptor's mcpp = { ... }
    segment? The message comes from the template/scaffold fetch path, which
    looks for a manifest inside the fetched package.
  • Whether the template flow and the ordinary dependency flow disagree about
    which of those two forms is acceptable — an ordinary [dependencies] use
    of compat.imgui is not reported failing, which would make this specific
    to the scaffold path.

Secondary observation in the same runs

The same jobs print

error: index requires mcpp >= 0.0.101 but this is mcpp 0.0.100 [E0006]

That one was the workspace bootstrap pin in .xlings.json lagging the index
floor; fixed by b5dece0 (pin -> 0.0.102). It is unrelated to the template
failure, which continues after it.

Environment

ci-fresh-install on ubuntu-24.04 / macOS ARM64 / windows, mcpp installed
from the published release via install.sh.

Activity

  1. xv1rcn commented on Jul 22, 2026

    @xv1rcn
    Contributor

    Root cause

    The namespace discovery loop in fetch_template_package() searches for template packages by bare name. xpkg_lua_candidates("", "imgui") generates ["imgui.lua", "compat.imgui.lua"] — both pass the identity check in discovery mode (only the short name is verified). If imgui.lua is unavailable for any reason (index floor check, partial clone, etc.), the fallback to compat.imgui.lua succeeds.

    compat.imgui is a Form B package (mcpp = { ... }): its manifest is synthesized from the index descriptor. The extracted tarball (upstream ocornut/imgui) has no mcpp.toml. The normal dependency path (prepare.cppm) handles this via McppField::TableBody → synthesize_from_xpkg_lua(), but fetch_template_package() did not — it directly checked the filesystem for a physical mcpp.toml and failed with a confusing error message.

    Fix

    src/scaffold/create.cppm (+4 lines): after reading the xpkg lua descriptor, check mcpp::manifest::extract_mcpp_field(). If the kind is McppField::TableBody, skip to the next namespace candidate via continue. This mirrors the Form A/B dispatch already present in prepare.cppm.

    Test

    Extended tests/e2e/69_package_templates.sh with a hermetic Form B compat package that reproduces the exact failure. Verified the fix locally and with related E2E tests (02, 12, 27) — no regressions.

    PR: #266

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions