You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

5.2 KiB

G-114 Per-platform tm module roots: platform-segregated binary .tm via tcl::path

Status: proposed Scope: src/vfs/_config/punk_main.tcl + src/vfs/_config/project_main.tcl + src/make.tcl (boot tm-path wiring); src/modules/punk/platform-999999.0a1.0.tm (canon names, as consumer); new per-platform tm root trees (layout/naming decision - sibling roots beside src/vendormodules_tclX / src/modules_tclX); src/project_layouts (layout seeding); modpod demonstration artifact; tree READMEs; coordinates with G-109 (manifest target-platform field stays that goal's item) Goal: binary-bearing .tm modules (modpods) are distributed ONE PLATFORM PER FILE and installed under per-platform TM ROOTS that the boot registers only for the running platform (canonical punk::platform names) - so no consumer downloads other platforms' binaries, a user can drop in their platform's copy of a same-name-version module without same-version shadowing, and wrong-platform .tm files present on a shared or synced tree are never registered or loaded. Acceptance: the root layout + naming decision is recorded in this file (including the structural constraint that platform dirs cannot nest inside an existing tm root - tm subdirectories are namespace components - so per-platform roots are sibling trees); the boot (punk_main.tcl, project_main.tcl, make.tcl) registers exactly the running platform's root(s), verified on the tcl9 kit and an 8.6 shell (or the 8.6 limitation recorded); a demonstration binary modpod .tm placed in the win32-x86_64 root loads via package require on windows while a same-name-version copy placed in a foreign platform's root is demonstrably not registered; the same-version drop-in-replacement scenario (the fat-tm objection) is demonstrated working across platform roots; generated-project layouts seed the structure; tree READMEs and punk::platform docs updated.

Context

Drafted 2026-07-22 from the platform-canon survey discussion (user-approved wording). Motivating evidence is the user's prior fat-tm experience, recorded in G-109 Notes the same day: a multi-platform thread .tm proved unworkable - (a) downloads far larger than any one consumer needs, and (b) same-version shadowing: tm handling resolves one name-version to ONE file with no arch awareness, so a user cannot drop in a replacement .tm carrying their platform when a same-version copy is already on the path. Platform segregation for binary .tm therefore has to ride tcl::path - per-platform tm roots selected by the boot for the running platform.

Structural constraint driving the layout decision: platform directories canNOT nest inside an existing tm root, because a subdirectory of a tm path is a NAMESPACE component (foo/bar-1.0.tm = package foo::bar - see src/vendormodules_tcl8/tdbc/sqlite3-1.1.5.tm = tdbc::sqlite3 for the legitimate use of subdirs). Per-platform roots must therefore be SIBLING trees registered separately (candidate shapes: vendormodules_tcl-/ siblings, or a byplatform// parent) - the naming decision is this goal's first item.

Division of labour with G-109 (libunknown manifest-declared multi-name discovery): this goal owns the roots, the boot wiring and the demonstration; G-109 owns the manifest format, where a declared target-platform field would additionally let libunknown skip wrong-platform binary .tm even when someone shares a path (defensive extra recorded in G-109 Notes 2026-07-22).

Related: G-066 (modpod generation - the demonstration artifact's tooling; self-mounting binary modpods characterized working there), G-110 (the binary inside a .tm loads via the extraction path investigated there), G-034 (8.6 modpod mount path - bears on the 8.6 leg of acceptance), punk::platform (canonical platform names; 'help platforms').

Provenance boundary (2026-07-22 user framing, G-004): the binary .tm these roots hold are NEVER checked into punkshell - they arrive via the G-067 artifact channel (punkbin library-class artifacts, consent-gated) or as local uncommitted drop-ins, and the same-version drop-in acceptance below is the tm-side expression of G-004's binaries-must-still-operate-in-tree requirement. Derived projects may commit them under their own binary policy.

Nothing needs this until binary-bearing .tm distribution starts in earnest - creating empty tm-root siblings ahead of that machinery would be speculative structure (2026-07-22 assessment). The goal exists so the layout and boot work land deliberately when G-109-era binary tms arrive, not ad hoc.

Notes

  • G-105 relationship (recorded 2026-07-24 after overlap review; neither file previously referenced the other): G-105's cross-target platform-dir naming (zig-triple <-> canon mapping, per-target artifact layout) and this goal's per-platform tm roots share the punk::platform canon settled in the same 2026-07-21/22 survey - root naming follows the canon, never zig triples.
  • G-133 (archived) is this goal's detection-side sibling, now landed: the bake's advisory binary-arch scan + smoke-require probe DETECT wrong-platform binaries/resolution at bake time for whatever layout a payload has, while this goal would PREVENT wrong-platform binary .tm registration at runtime - see goals/archive/G-133-bake-payload-consistency-checks.md.