We should permit wkg registry names (bare domain) here with the /.well-known/wasm-pkg/registry.json indirection.

Alternatively we could specify a slightly different syntax that implies this lookup, like

targets = ["my.org/my-env@1.0"]

This would look up the oci prefix at https://my.org/.well-known/wasm-pkg/registry.json and use it to construct an oci reference like ghcr.io/my-org/my-env:1.0. If we wanted to mechanically avoid conflicts between environments and regular wasm packages we could stick another substring in there e.g. ghcr.io/my-org/my-env:spin-env-1.0 or ghcr.io/my-org/spin-env/my-env:1.0 or something.

@lann These entries point to TOML documents not WIT documents. (The TOML documents then point onward to WIT documents, which are typically wkg package references.)

Sure; I'm suggesting that we could reuse the domain -> OCI mapping that wkg already implements to allow nicer specifications of targets from registries.

Ah sorry thanks for the clarification

This feels like a convenience feature we could add without breaking back compat if the feature achieves traction? Or are we sufficiently confident that other folks will be publishing environment TOMLs that we need to offer this in the first drop?

This makes me wonder if we should accept e.g. { trigger_type = "redis", world = "spin:up/redis-trigger@3.2.0" } as a valid target.

I guess a slightly more verbose but flexible way to get the same effect would be allowing inline environment definitions. 🤷

Or maybe the target could be just the world reference? While that wouldn't have explicit trigger types those can be sort of inferred from the manifest itself. 🤔

@lann I am wary of that for two reasons:

1. It breaks down as soon as multi-trigger-type enters play - you find yourself needing to infer which world corresponds to which trigger type. We tried that and it was terrible.
2. It breaks the "I want to make sure I can deploy to..." abstraction. The goal here is for the developer to say "I want this to run on Wasmtime 35, Spin 3.2, and SpinKube 3.1." If I want to target spin:up/http-trigger@3.2.0, and figure out for myself whether that's compatible with SpinKube 3.1, then I have the tools to do that. The idea is to take care of "knowing which worlds a host supports" for you.

I'm not opposed to inline environments as an escape hatch, but I'd like them to be defined in the same way as other environments, and at that point I don't see a vast amount of value compared to putting them in a my-environment.toml file.