Different label naming conventions for KV stores vs AI models

[kate-goldenring]

In the Spin manifest, i cannot label a KV store with kebabcase. key_value_stores = [ "has-hyphen"] will cause the following error:

Error: TOML parse error at line 17, column 20
   |
17 | key_value_stores = ["has-hyphen"]
   |                    ^^^^^^^^^^
words must be separated with '_', not '-'

However, labels for llm models must be hyphenated and the following fails ai_models = ["llama2_chat"].

We have clearly defined this limitation in the Component type, so the TOML parser correctly throws the error:

    /// `key_value_stores = ["default"]`
    #[serde(default, skip_serializing_if = "Vec::is_empty")]
    pub key_value_stores: Vec<SnakeId>,
    /// `sqlite_databases = ["default"]`
    #[serde(default, skip_serializing_if = "Vec::is_empty")]
    pub sqlite_databases: Vec<SnakeId>,
    /// `ai_models = ["llama2-chat"]`
    #[serde(default, skip_serializing_if = "Vec::is_empty")]
    pub ai_models: Vec<KebabId>,

My main question is why we specify snake case for some and kebab for others. Could we permit both?

[itowlson]

Huh. I thought at one point all were required to be hyphenated because they could in future be thought of as individual imports, though I am not sure we worry about that any more. @lann any idea why these are required to be snaked?

[kate-goldenring]

Yeah, Fermyon cloud currently requires them to be hyphenated, so i was surprised by Spin having a different requirement

[lann]

I don't remember exactly how we ended up in this situation but it would be good if labels could be represented as kebab-case, either by requiring them to be kebab-case themselves or having a simple rule to convert them.

[kate-goldenring]

To prevent a breaking change, we probably cannot change pub key_value_stores: Vec<SnakeId> to pub key_value_stores: Vec<KebabId> but as you mention, @lann we could add custom serialization.

[itowlson]

What is the outcome here (for the 2.x timeframe) - allow kebab or snake case?

I don't quite get the discussion around converting. Is the idea that internally they'd be represented as kebab-ids? And we would also convert snakeful references (e.g. Store::open("my_snek")) to match the kebab-id?

[lann]

I guess my perspective is that I don't want to make major breaking changes to the manifest format but it would be good to have a plan for how to map labels to kebab-case names in the future, which could involve making minor changes to the label validation rules (in particular, kebab-case "words" between -s cannot start with a number).

[kate-goldenring]

For now, could we change the manifest to allow kebab or snake case and then when we are ready to break, we remove snake? Fermyon cloud can continue to only support kebab

[lann]

WFM but I don't currently have a good mental model of how all these things currently work so I'll defer to others.