Skip to content

Apps choose fizzy's plugins, and can link only #2

Open

Description

@foxnne

An app built on fizzy (Graphl first) wants to choose which of fizzy's plugins it links, and to run with linked plugins only: no dylibs, no user plugins directory, no store.

Today fizzy.buildApp always links all six of fizzy's plugins and appends the app's own after them (build/exe.zig; build/web.zig and the test build in build/app.zig each keep a second and third copy of the list). An app can't leave any of them out. It also isn't link-only:

  • The four built-in dylibs (workbench, text, markdown, image) are still built and installed, and at startup a dylib beside the exe wins over the linked copy (App.bundledDylibEnabled).
  • loadUserPlugins still scans <config>/plugins/.
  • Only the store can be turned off (-Dapp-registry-url=, empty).

text and markdown can't be fetched on their own: each build.zig.zon points at ../../sdk. They version with the fizzy commit an app pins, which is fine, because they are tied to that commit's SDK and core/ anyway.

Decided: no published "builtin bundle" package. A bundle would just be a list of modules, which Zig dependencies already give you, and it would add a release train that can disagree with the SDK the app links. If an app ever needs text on its own cadence, the answer is the pixi route (its own repo, plugin-build-action), not a bundle.

  • 1. build: fizzy's plugins are entries an app lists. fizzy.plugins.{workbench,text,image,archive,markdown,devtools} are BundledPlugins, and buildApp links exactly the list it is given. Fizzy's own build.zig passes its six the same way, so one list feeds the exe and web builds (the test build keeps its own, since it tests fizzy itself), and fizzy's list is just one more app's list. workbench stays required for now, because Editor still holds its state (editor.workbench, passed as the dylib's arg_c); it becomes optional when that state moves into the plugin (roadmap#4). example-app updates in the same change. (build: an app lists the fizzy plugins it links fizzy#441; build: fizzy's plugins are listed; the minimal shape links two example-app#6. Until example-app lists fizzy's plugins, a list naming none of them gets all of them, because each repo's CI builds the other's main.)

  • 2. app: a link-only build (app: a link-only build, which loads no plugin at runtime fizzy#445). A build option (.@"dynamic-plugins" = false on the fizzy dependency, or -Ddynamic-plugins=false) does four things:

    • skips building and installing the built-in dylibs
    • compiles out the dylib probe in postInit
    • compiles out loadUserPlugins
    • turns the store off

    It is a comptime build_opts flag, like wasm's: nothing is checked at runtime. Fizzy's CI compiles it on Linux.

  • 3. build: drop step 1's fallback once example-app#6 is on its main; example-app gets a link-only build in its CI and in check-examples.sh once 2 is merged.

Also: fix the stale comment at src/editor/Editor.zig postInit that says the bundled plugins don't ship as dylibs. They do; the comment should say why (the built-ins exercise the dylib path, the same way third-party plugins load).

🤖 Generated with Claude Code

Activity

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