Provide the ability to import manifest and runtime-config as wasm modules (components)

[mikkelhegn]

Instead of relying of toml for a Spin manifest and runtime config, in certain scenarios it would be great to be able to provide those as WASM modules (components), if e.g. you want to generate these programmatically.

[lann]

Could you provide more detail on use cases here? Doing something like this for the manifest would be an almost entirely separate feature from runtime config, and even for manifests there are at least two distinct places where we could do this generation depending on exact goals.

[lann]

I think this overlaps with some of what @tschneidereit has been thinking about with build-time customization.

[mikkelhegn]

@tschneidereit / @lann is there a reference to

build-time customization

[mikkelhegn]

Could you provide more detail on use cases here?

In the Aspire integration, @ThorstenHans has had to generate toml as part of the integration: https://github.com/fermyon/Aspire.Spin/blob/e1a676a5de27ba42b87da9d82254a15885449d97/Aspire.Hosting.Spin/RuntimeConfiguration/RuntimeConfiguration.cs#L22 - it would be nice if this could be easier for scenarios like this.

@ThorstenHans feel free to add more details.

[tschneidereit]

@mikkelhegn there isn't yet: I've been talking about this with a few people, but haven't written anything down so far, as it's not yet crystalized enough

[lann]

In the Aspire integration, @ThorstenHans has had to generate toml as part of the integration

If it helps, Spin also now accepts JSON for runtime config.

[ThorstenHans]

In the Aspire integration, @ThorstenHans has had to generate toml as part of the integration

If it helps, Spin also now accepts JSON for runtime config.

Do we have a JSON schema somewhere?

[lann]

Do we have a JSON schema somewhere?

Nope. The schema is defined here (though honestly that isn't very useful if you aren't deeply familiar with surrounding code): https://github.com/fermyon/spin/blob/main/crates/trigger/src/runtime_config.rs#L198

Relevant parts should look like e.g.:

{
  "key_value_store": {
    "default": { "type": "redis", ... },
    "other": { "type": "azure_cosmos", ... }}
  },
  "sqlite_database": {
    "default": { "type": "spin", ... }
  },
  "llm_compute": { "type": "remote_http", ... }
}

(you should also be able to adapt any existing toml example with any toml-to-json converter like https://transform.tools/toml-to-json)

[ThorstenHans]

I was asking for a schema because that would allow me to get nice auto completion when creating new runtime configuration files.

Thanks @lann

[lann]

I was asking for a schema because that would allow me to get nice auto completion when creating new runtime configuration files.

:+1: I'll keep this in mind for the Spin Factors project; I think there should be a nice way to generate JSON schema.

[mikkelhegn]

@lann did this happen?

I'll keep this in mind for the Spin Factors project; I think there should be a nice way to generate JSON schema.

If it has been made simpler to programmatically provide runtime-config, I think we can close this issue.

[lann]

There has been no change here, though I also don't think we've had much feedback on runtime config in general.

[mikkelhegn]

Agreed. I'll close this for now as I don't think there are any urgent use-cases I know of which will need this.