Template: Extend it to include more capabilities

[Mossaka]

Describe the solution you'd like

Currently when I do slight new -n spidey@v0.4.0 rust, it will create a rust bin program that has a main.rs and some code to use the keyvalue capability. This is great to get people start using slight right away, but also lack significantly for other use cases. For example, a common use case for slight is to set up a HTTP server and handles HTTP requests using http-server capability. In order to create one application like this, I need to manually edit Cargo.toml to include [lib] section and rename main.rs to lib.rs in order to use the WASI reactor model.

Solution

We want slight new to not only take a programming language name like C or Rust, but also a capability / service. This means we would maintain a 3D matrix of capability name, service name and language name to get people started with creating slight applications.

slight new -n spidey -l rust -c http-server -v 0.4.0 or slight new -n spidey -l rust -c keyvalue -s redis -v 0.4.0

The above two command examples show how users can create different slight application with one simple command.

Alternatively

We could build a CLI that asks user questions on what kind of project they want to get started, and use all the answers to build a templated project for them .

slight new
> name: 
spidey
> langauge:
rust
> capabilities (seperated by comma)
http-server, keyvalue
> services (seperated by comma)
keyvalue.azblob, keyvalue. 
> version
0.4 <-
0.3
0.2
...

✔️ building a spidey...
✔️ finished... 

Additional context

[danbugs]

I think slight new -n spidey -l rust -c keyvalue -s redis -v 0.4.0 is very messy and error prone.

The thing is: slight new -n spidey@v0.4.0 rust is not meant to be something that covers all use-cases. Instead, after running slight new, if people want to add other capabilities they can use slight add.

For example, while I was crafting my WasmIO demo, I did:

slight new -n wasmio-demo@v0.4.0 rust && cd wasmio-demo
cd wit && slight add messaging@0.4.0

[Mossaka]

I guess my main point is that the current new command creates a slight application that automatically adds the keyvalue interface in, which probably isn't what the user wants. In addition to that, the way we use slight http-server capability requires users to edit many files:

• rename main.rs to lib.rs
• add [lib] section to Cargo.toml
• add http-server capability
• add slight macro dependencies to Cargo.toml

This isn't a great experience imo.

[danbugs]

I guess my main point is that the current new command creates a slight application that automatically adds the keyvalue interface in, which probably isn't what the user wants. In addition to that, the way we use slight http-server capability requires users to edit many files:

• rename main.rs to lib.rs
• add [lib] section to Cargo.toml
• add http-server capability
• add slight macro dependencies to Cargo.toml

This isn't a great experience imo.

I agree that users might not always want keyvalue, but that template is just the most basic one we have w/ the most basic application possible. To fit other users needs, we need to create other templates – for your example, that would be smt like http-rust.

Also, I think our current template does have the slight macro dependency already added to the Cargo.toml, and all the other changes required that you mentioned are because of recent code changes.

[Mossaka]

this sounds good to me. I will be working on a http-server-rust template for http-server template.

Another concern of mine is how we can maintain the templates - each time we bump up the CLI version, we will have to bump up the version used in the templates. Any mistakes in this process would cause a re-deployment. Can we somehow make the dep versions in the templates aligned with CLI version automatically?