Skip to content

id: design: Roc library imports for worlds — pure dependencies and platform-dependent dependencies #5956

Open

Description

@dezren39

Part of the worlds design program: #5955. Statements S1–S4 of the 2026-11-04 brief.

Requirement (Drew, in substance)

Design how more advanced Roc libraries work for worlds, in detail:

  • Worlds must, at a minimum, be able to import pure dependencies.
  • Worlds may also be allowed to import whatever dependencies they want — how far this goes is an open design question, not a default yes.
  • A dependency may rely on platform capabilities and therefore be technically not pure, yet still be importable by a world/app. The import system has to represent that honestly: a library's purity is a function of the platform surface it touches, not a binary label the author asserts.

Open questions

  • How does a Roc package declare the platform functions it uses, and how does the world compiler check that set against the compiling platform's catalog (pkgs/id/crates/id-core/src/world_caps.rs) at import time?
  • Do platform-dependent libraries resolve against the world's platform, or do they carry their own platform requirement that must be a subset of the world's?
  • What is the failure mode and error quality when an import's platform needs exceed the platform (see the demo task's negative tests)?
  • Where do imported libraries come from: URL, registry, upload — and how does that interact with the library typing design in the taxonomy child of #5955?

Related

  • Core/app platform design: #2028
  • Roc libraries shipped Phases 9–10, verification debt: #796
  • Capability-provider parent: #5686

Done looks like

A design doc section (or standalone doc) covering: import resolution, platform-requirement representation for libraries, subset checking against the platform catalog, and error behavior — sufficient to implement the demo task without further design decisions.

Activity

  1. added
    priority/normalOrdinary priority (the default)
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    kind/designA design proposal (design-architect): multi-step, phased, decision-bearing
    on Nov 5, 2026
  2. developing-today commented on Nov 5, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Wave-2 tie-in (conversation archaeology, findings F7 + F10) — start from what shipped.

    • Phases 9–10 already delivered the first version of this design space: Roc libraries, execution profiles, and capability ceilings shipped — explicitly "faster than verified," with the verification debt tracked in #796. This design is an extension of a shipped mechanism, and the demo + negative tests in the demo task under #5955 are verification-debt repayment as much as new feature.
    • Settled architecture this design cites rather than re-derives: the capability catalog lives in pkgs/id/crates/id-core/src/world_caps.rs (time.now/tick, random.u64, players(.list), chat.say/history, records.read, schedule.at/cancel, world.info + modules Key, Screen, RocJson, RocGrid, RocCap, RocText), and imports are checked against the world's ceiling at compile time. No file or network capability exists in the catalog today.

    Record: workspace/scratch/worlds-capabilities-brief-2026-11-04/conversation-tie-ins.md (F7, F10).

  4. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Wave-2 follow-ups filed from the prior-art research (Lane B). Granular sub-scopes of this issue, each carrying the relevant research findings + citations:

    Research source: workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md. Full wave-2 mapping: workspace/scratch/worlds-capabilities-brief-2026-11-04/wave2-map.md.

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

    app/idPackage/app: id (pkgs/ or apps/ in this repo)kind/designA design proposal (design-architect): multi-step, phased, decision-bearingpriority/normalOrdinary priority (the default)status/needs-triageNot yet triaged; needs a first look

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions