Configurable (or additional) plugin directory search paths

[endocrimes]

Because Spin Plugin binaries are precompiled binaries with a variety of system dependencies, they may not run as-built-by-Fermyon on all systems - for example spin cloud doesn't run on NixOS because the ELF interpreter and openssl have a different path (see also our GLIBC version issues in the past on ubuntu).

It would be helpful to allow package managers to distribute Spin Plugins to account for this (and also means that plugins can be reliably updated in the same manner as people otherwise manage their systems).

[itowlson]

Let me see if I understand the context here.

The underlying issue is that, for some systems, the pre-built binaries for a plugin don't work.

A part of the solution for that is for them to be packaged. I don't have enough experience to be clear what this entails - I guess the distro maintainers rebuild the binaries, so that they are compatible, and register them in a package manager? I think I am missing some understanding here.

However this is still not sufficient because Spin will still try to install its prebuilt binaries and run them from the prescribed place. The proposal is that users will install the packaged versions manually from the package manager (bypassing spin plugin install). Is that correct? The requirement on Spin is therefore to allow users to specify "this is where my package manager installs plugin binaries".

For example, we could define an environment variable such that, if the EV is present, Spin runs "EV value + plugin name" instead of the plugin store path, and simply fails if that does not exist or is not executable. Spin does not need to care how binaries get into that directory.

• Is it okay if spin plugins commands such as list and uninstall return incorrect results?
• Is it okay if plugin commands are not displayed in spin --help?
• Do we expect plugin binaries to be named for the command (e.g. cloud) or to be prefixed as in some other plugin systems (e.g. spin-cloud)?

Sorry for what may seem obvious questions, I am just trying to get my head around the context of the problem, the broader solution, and the extent of what Spin needs to do to enable the solution.

[itowlson]

I should clarify that Spin currently does not have a directory of plugin binaries; each plugin is stored in a different directory, under a common base, and Spin invokes the binary by deriving its full path. So there is currently no notion of "directory search" (not to say we couldn't add it, just providing background on how it works today).

[itowlson]

A possible challenge with an entirely flat structure is that plugins may have assets that are installed alongside the binary (I think this is a reason for Spin giving each its own directory). At the moment I think the only one this applies to is cloud-gpu (and recent work may obviate the need for it to have them), but I'd not want to rule it out. Would that be a problem for the manual install / package manager approach?

[itowlson]

@endocrimes I sent a draft PR - quite possibly jumping the gun, but so that it was quicker to iterate if my interpretation was correct (or, indeed, if it wasn't).

[jandubois]

Wouldn't a better solution be for Fermyon to also offer the plugins statically linked? I wrote about this in #2555 that even though there are static-linux builds of spin (e.g. https://github.com/fermyon/spin/releases/download/v2.5.1/spin-v2.5.1-static-linux-amd64.tar.gz), these builds will still install dynamically linked plugins, that most likely won't work.

If static-linux would be treated as a separate platform, then spin plugin install … could automatically install the compatible version.

Or am I missing something, and are there platforms that would not support the statically linked builds?