extensions and differing language runtime version requirements

[airtonix]

I saw you have a extension page https://www.zot.sh/docs/extensions

so i pick a whole bunch and loaded zot up.

then i ran zot.

The major problem i had is that some of the extensions are written in golang, each with differing required runtimes. (so they didn't launch and zot never finished loading)

It's awesome that i can use what ever language i want for extensions.

What i'd like to discuss here is how does zot execute those extensions?
in a subshell? some other way?

Answer: it executes the exec entrypoint in the extensions dir.

As a heavy mise user, my user land has a mise.toml with golang 1.18 in it. (this is why the extensions crashed)

I'm wondering if we can encourage people to use mise and also if adding a mise.toml to the extension root would allow the extensions to all run with their own language runtime required.

If zot executes plugins via subshell in the extension dir, then this will already happen now.

tldr:

encourage people to lean on mise, and provide mise.toml with tooling required in their extensions.

[frkr]

I'm in favor of running in several languages and versions. But how to do that? In node I know, but how would you do it in Go?

[airtonix]

I think best thing you could do is to test if the language then exec exists.

if not then the extension load failure message could mention this?

[airtonix]

something like this #173

[frkr]

I liked it. So much so that it has already been implemented. The idea where an extension that is plug and play is very inviting but let's remember that zot is still a CLI tool for advanced user.

Creating obstacles for those who create extensions is not the best option. But why don't we think about how to make better extensions so that they are plug and play?

This approach of language and exec creates a layer of comfort but we must worry about how to create better extensions and how.

You mentioned WASM, but there is still Node and Go. Which, in theory, are multiplatform.

When zot is updated via brew or by zot update should we check these variables?

[airtonix]

I posted below an idea of installing from github releases as well as zots current git clone behaviour.

At the moment you could just compile your entrypoint to binary and commit the binary back to the repo so that your manifest entrypoint points at the binary.

But if we support installing from github releases, then it allows a more suitable place to store those binaries.

You mentioned WASM, but there is still Node and Go. Which, in theory, are multiplatform.

I briefly mentioned wasm, because it doesn't need the zot user to have anything special in order to use a wasm extension (zot would bundle this capability). I assumed that all languages have a way to compile themselves to wasm.

Thinking more about this, wasm brings other restrictions that aren't helpful for zot extensions.

[lovehumans]

Few things are as annoying as asking the user to replicate your dev environment to get your code running.

If one of zot's main draws is that it's a statically linked binary that just works, the same should be true of zot's extensions.

[airtonix]

agree, but for some reason my smooth brain thinks WASM is the only solution to this?

(I think this is why Zellij plugins are expected to be WASM)

If only mise had a sdk ?

I guess you could embed mise into zot binary ?

[airtonix]

Perhaps a compromise could be that zot supports wasm extensions and this is the recommended path for publicly distributed extensions?

Still support extensions in any language that can be executed on users system.

[airtonix]

A variant on this might be how zot installs extensions, simply support installing packaged extensions from github releases ?

this way bun,rust,go,java, etc can compile their entrypoint to binary and make it part of the bundle.

[airtonix]

A possible way to address the runtime/version problem would be to make GitHub Releases a first-class extension distribution mechanism, while keeping local-directory and Git installs for development.

Proposed commands:

zot ext install github.com/owner/repo
zot ext install github.com/owner/repo@v1.2.3
zot ext update <name>
zot ext update --all

An extension release could publish platform-specific assets such as:

<name>_<version>_<os>_<arch>.tar.gz
<name>_<version>_<os>_<arch>.zip

plus an any asset for scripts, themes, or other runtime-independent extensions. Each archive would contain the existing extension.json and all files needed to run the extension. A checksums.txt asset would allow zot to verify downloads before installation.

Installed extensions should be recorded in the existing $ZOT_HOME/settings.json, for example under an extensions object:

{
  "extensions": {
    "weather": {
      "source": "github.com/acme/zot-weather",
      "version": "v1.2.3",
      "commit": "abc123",
      "asset": "weather_1.2.3_linux_amd64.tar.gz",
      "sha256": "..."
    }
  },
  "extensions_check_for_updates": true
}

This would also give zot ext install a useful no-argument form: without an extension reference, it could install any missing extensions described in settings.json rather than failing with a usage error. Launching zot could perform the same reconciliation automatically, ensuring configured extensions are present. It could optionally check for updates to extensions whose version references are vague (for example, an unpinned repository or latest). Users should be able to disable that network check with a setting such as extensions_check_for_updates: false.

The install flow would be:

1. Resolve the repository and optional version through the GitHub Releases API.
2. Select the asset matching the current OS and architecture, falling back to any.
3. Download and verify the checksum.
4. Extract into a temporary staging directory with path-traversal and symlink checks.
5. Validate extension.json and its executable paths.
6. Atomically install it under $ZOT_HOME/extensions/<name>/.
7. Record the resolved release, commit, asset, and digest in settings.json.

zot ext update could use that provenance to install a newer release using the same staged, verified, atomic replacement flow. I would keep extension updates explicit rather than having zot update silently replace extensions; startup could check for updates only when enabled in settings, and should avoid blocking normal startup on a network failure.

This would let extension authors ship prebuilt binaries and avoid imposing Go/Node/Python version requirements on users, while preserving the existing source-based workflows for development. Security-wise, release installation should require HTTPS, verify checksums, reject unsafe archive entries, avoid install hooks/package-manager execution, and show the selected repository, release, and asset before installation. Checksums provide integrity but not independent publisher authentication, so signed releases or Sigstore attestations could be added later.

Implementation-wise, the existing download, checksum, and archive helpers in the zot updater could be reused for extensions, with GitHub release resolution and safe extraction factored into shared code. Tests should use a local HTTP server and cover platform selection, checksum failures, malformed archives, rollback behavior, settings reconciliation, and disabled update checks.