Different label naming conventions for KV stores vs AI models about spin HOT 8 CLOSED

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?

from spin.

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

from spin.

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.

from spin.

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.

from spin.

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?

from spin.

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).

from spin.

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

from spin.

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

from spin.