Make cargo shuttle init interactive

[brokad]

Currently, to initialise a project with the right stub for different frameworks, we use cargo shuttle init with a set of mutually exclusive options (e.g. --axum, --poem etc).

We'd like an interactive route into this where cargo shuttle init prompts:

• The login flow, if the user is not logged in yet
• The name of the project to be deployed (indicating this will mean the project will be hosted at ${project_name}.shuttleapp.rs)
• A multi-choice for all supported frameworks
• Asks if the users wants the environment for the project to be created on shuttle, and chain into it if yes

[Procrat]

I'm happy to help out with this!

Did you still want to keep the non-interactive route around? If so, do we want it to only be triggered when all arguments are specified (inc. name and path)? If not, would there be any point in keeping those parameters?

[oddgrd]

Awesome, thanks @Procrat! Imo we can keep it around, it could be useful for programmatic calls and some users may prefer it over interactive cli. So currently the path is not required and the default is ., meaning if you init without it the current dir will be used and the name of this dir will be the crate and project name (unless you specify --name). So maybe the path should be required? I'm not a 100% on what the most ergonomic solution would be here.

By the way, there are some great crates for interactive CLI's. I haven't used them myself yet, but I've seen them used in some good CLI's (like cargo-lambda): https://crates.io/crates/inquire and https://crates.io/crates/indicatif.

[brokad]

Imo we can keep it around

I agree. What would be really nice IMO is if any missing option or parameter is prompted and nothing gets prompted if all required parameters are given. That way cargo shuttle init --name="my-project" would not prompt for project name but will prompt for a framework choice.

[Procrat]

Thanks for the input! I've made a repo with a toy version of the interactive flow here in case you already wanted to give it a go and give some early feedback.

Just to make sure we're on the same page, the interactive and non-interactive versions behave quite differently here. Whereas the non-interactive one (as it is now) just performs actions locally, the interactive one will also log in and create the environment on Shuttle. It might be a bit confusing that the scope of the command changes based on a flag, but I can see it's user-friendly to do everything in one go.

@oddgrd: I had already started with dialoguer instead of inquire although I did try them both out first. Happy to switch if you have a strong opinion about it though! I just chose it because it had fewer dependencies and seemed to have everything we needed.

[oddgrd]

No opinion, feel free to use whichever crate fits best!

That is a good point, originally the plan was to have just the boilerplate generation be interactive, so it would have been the same. I think tying it all together would be nice for the user though, like you said, so that cargo shuttle init is the only thing they need to know to get started with a hello-world app. Maybe we just continue with both, and see how we feel about it in the end?

[brokad]

Just to make sure we're on the same page, the interactive and non-interactive versions behave quite differently here.

That's a good point! My two cents on this: we could retrofit the new behavior to the original command and adjust my proposal somewhat.

How about this: the user only needs to be logged in if they desire to create the new project straight away. So maybe in the non-interactive route we add an optional flag to create the project on shuttle (--new?). Then, starting the login flow is an implicit action attached to --new in case we're not authenticated. If --new is not specified, in the non-interactive route (i.e. all parameters are set), the old behavior applies (the project is not created); whereas in the interactive route (i.e. some parameter is missing) we prompt for it.

@oddgrd makes a good point it may be simpler to break this up into two issues: making the existing behavior interactive (ignoring creation and authentication for now), and expanding the behavior of init to include project creation (and dependent authentication). Whatever is easier 😄

[oddgrd]

I checked out your repo now, and I think it looks really good already. Some neat details too, like the api-key being hidden and the dir being set to the name by default, nice!

One point, and this is very subjective, is it better if we clear the terminal between prompts?

[Procrat]

Thanks for taking the time to think about this! That --new flag makes perfect sense to me. I'm still happy to do everything in one go.

I don't feel strongly about clearing the terminal or not. Any opinions? At the moment, I didn't because I personally like to see the history of what I did in a terminal, but that's just one person's opinion 😄