`spin new`: provide application name without providing template about spin

[michelleN]

I'd enjoy spin new [app_name] -t <template>.

spin new [app_name] -t where <template> is omitted gives you all the templates available to choose from.

spin new [app_name] with no flags gives you just a spin.toml file in a directory called [app_name]

wdyt?

[fibonacci1729]

+1 to what Michelle said. The only other request I would like to see is a --init that initializes the current directory rather than creating a new directory.

[mikkelhegn]

I guess that would address this as well #1075 - which might be a dup of #16

[itowlson]

@fibonacci1729 In that case, could/should the template name be positional, or is it better to put it behind the -t flag? (I'm not trying to argue for a specific outcome here, just figuring out the design space.)

Also I know @michelleN has been arguing for the "just create a spin.toml file" for a looong time and I do want to understand the intended experience because I am sure I am missing something.

[itowlson]

@fibonacci1729 Interesting! I wonder if we should use the --from trick we do on spin up so the user could write spin new myapp -f http-go or spin new myapp -f component.wasm or spin new myapp -f path/to/spec interchangeably, and we figure out which case it is. (With --from-template/--from-component/--from-openapi longopts if disambiguation is needed.)

[fibonacci1729]

@itowlson I think you are right but i'd still prefer the --init because my expectation for -o all this time had been that a directory named appname would be created at the value of -o. TIL

EDIT: confirmed that -o . <==> --init

[itowlson]

Yeah we should maybe have done this the other way round...

The only things I can think of are:

1. Allow the name as a named parameter as well as a positional one (clap permitting). So your command would become spin new --name myapp.
2. Have a magic syntax for "prompt me for the template ID" e.g. spin new * myapp.
3. Not quite what you asked for, but allow partial/tag matches in the template ID, so you could write spin new rust myapp and it would go "here are all your Rust templates."

Of these, the last feels most comfortable but I don't know if would meet what you want to write.

[rylev]

The PR you opened seems reasonable. I current ordering is a bit unfortunate, but alas, perhaps this is the best we can do.

[itowlson]

We could have a rule that if there is one positional arg and it doesn't match a template (possibly within some fancy distance metric), we prompt for the template, and prompt for the name but default it to the positional arg. It feels a bit hairy but would probably work in the 90% case.

More generally we could try harder to make sense of "incorrect" user input e.g. if first arg does not match a template but second one does then quietly swap them. I am slightly wary of teaching people the "wrong" thing, though, because things where we can resolve the ambiguities in interactive mode today may not be resolvable in CI environments tomorrow.

[itowlson]

This has been marked as a "must have" (release blocker) for Spin 2. I believe the only proposal for implementing it is to reorder the arguments from spin new [<template>] [<name>] to spin new [<name>] [<template>]? This would allow users to omit the template. Is that correct?

If this is the proposal, it's an easy change in the code! However, anyone with muscle memory of the existing order would experience a jarring transition (and any scripts that use the existing order will break in non-obvious ways). Are we agreed that the joy it will bring over time is worth the short-term pain? (I'm guessing I'm one of the only people on the planet to actually have that muscle memory, so if it brings two people joy then that's probably a net win!) If so, are there ways we can cushion the change?

Or are there other proposals? We also have #16 in the frame which asks for a specific "empty application" experience., so it would be good to get a comprehensive sense of what we want the app scaffolding experience to look like across the various asks.

[itowlson]

(For example someone made mention of wanting to be able to create an application in the current directory. This can be done without a breaking change, but if it's a requirement/want then it would be good to have it in mind during any rethink.)

[itowlson]

Can we get a decision on required behaviour please. It's marked as a release blocker for 2.0 but without some agreement on the desired outcome there's no point starting to code. cc @melissaklein24

[mikkelhegn]

spin new [app_name] with no flags gives you just a spin.toml file in a directory called [app_name]

This seems to also solve #16

[itowlson]

Thanks all, appreciate getting some definition on this.

I don't quite get the "a spin.toml file in a directory." What is the spin.toml file? Is it the same as the current http-empty template? Is that the experience people want as the default, rather than the current "prompt for a template"? So if someone did a spin new myapp it would succeed but the created app would not yet be runnable?

[fibonacci1729]

Ah right, good catch. Personally, I don't see much value in spin new <appname> just generating a component/trigger-less spin.toml. I would think in this situation the user would be prompted for the template to select. In other words, in Michelle's above the -t flag requires an argument.

[fibonacci1729]

IIRC the rationale for the -t flag was because we may want to allow application scaffolding from artefacts other than a template in the near future. E.g. spin new myapp -w component.wasm or spin new myapp --openapi path/to/my/spec.

[itowlson]

I guess some flags might need extra args like an OpenAPI spec in Git might need a branch/rev option.

[fibonacci1729]

@fibonacci1729 Interesting! I wonder if we should use the --from trick we do on spin up so the user could write spin new myapp -f http-go or spin new myapp -f component.wasm or spin new myapp -f path/to/spec interchangeably, and we figure out which case it is. (With --from-template/--from-component/--from-openapi longopts if disambiguation is needed.)

That sounds like the best experience!

[itowlson]

Boo, we already use -f for the manifest to add to in spin add.

[michelleN]

Also I know @michelleN has been arguing for the "just create a spin.toml file" for a looong time and I do want to understand the intended experience because I am sure I am missing something.

I am envisioning a skeleton Spin.toml file for an http Spin app that contains some comments on how to fill in the fields.

spin_manifest_version = "1"
authors = ["Michelle Dhanani <[email protected]>"]
# add a description here
description = ""
name = "some-app"
# the trigger field is used to specify how components are invoked. the http trigger type is the most common # # Spin trigger. This allows components to be invoked via HTTP requests. There are other trigger types.. please see docs.
trigger = { type = "http" }
version = "0.1.0"

# Spin apps can consist of multiple [[component]] sections.
[[component]]
# id is a unique identifier for the component in this spin app, you can specify some alphanumeric string here <add constraints>
id = "component1"
# source is the path to the wasm file that will be executed when this component is invoked
source = ""
# allowed_http_hosts represents what hosts this component can make outbound http requests to
allowed_http_hosts = []
[component.trigger]
# route description here
route = "/..."
[component.build]
# command to build the component, will be used by Spin build
command = ""

[itowlson]

Thanks for clarifying @michelleN. If we do this I think we're going to need a significant amount of supporting infra to provide:

• Good error messages for when a beginner does spin build / spin up on one of these. At the moment I think you'd get some nasty parsing errors, when what it would need to do is recognise the "blank" manifest and say "hey you need to go back and fill out all those fields that spin new created for you."
• Improvements to spin add so that when a user added a component to one of these, it replaces the "blank" component instead of adding. (Because it's significantly easier to spin add than to write out all those commands and paths by hand.)

The challenge is that, unlike the empty scaffold, this looks like it has a component, so it requires more smarts to determine that actually there isn't a component, it's still waiting to be filled in. I worry that this leaves new users going "but how do I make it work" rather than having a working "hello world" starting point.

We can of course do this if people want it, but I'm wondering if there are other ways to accomplish the goal that this is aiming at. @michelleN is the motive here the doc comments, the "bring your own language", the not needing to install a template. something else?

[itowlson]

@fibonacci1729 Is the proposed --init flag equivalent to the existing -o flag with the path .?