`func create` command should default to confirm prompt

[nainaz]

Context

During User interviews. When users are creating functions, default choice of language wasn't the expected experience and confused them to think that Node is the only choice and doesn't let the user know that there are other choices available for language/runtime and/or templates. In addition, user had to consult the Help text multiple times and it resulted in disjointed experience.

Story

As Deandra the Developer I want to understand what options are available to me when creating a new function So that I become familiar with all of the options that func supports

Acceptance Criteria

• [ ] Guide the user through all the options available while creating func project

GIVEN I typed func create into my terminal 
WHEN I hit enter 
THEN I am guided by an interactive CLI (which currently requires -c flag) 

[omerbensaadon]

@nainaz I'm going to change this to default to -c the first time the user runs func create.

I will open another issues which asks the user if they would like to store their option as their default runtime...

Thoughts on this? @lance @lkingland @zroubalik where could this default be stored?

[lance]

@omerbensaadon we have a func config command that we have discussed adding things like this to. Currently func config affects only the local project, but the tentative plan is to have func config global to manage global configuration options such as this (or possibly func config -g.

Already, we store installed remote template repositories that have been added with func repo add in ~/.config/func/repositories. Global configuration such as the default runtime to use on create will be stored in a configuration file in ~/.config/func/config.yaml or similar.

[lkingland]

I am pretty sure the core problem here:

default choice of language wasn't the expected experience Will be solved by implementing the git-like behavior of prompting a user to provide the --language flag, but informing them this can be defaulted for future invocations using git config X --local. This might make changing the default behavior to the -c flow unnecessary, but we can take a look again at that time!

[nainaz]

Agree that, one factor is definitely the default choice of runtime. However, first time showing off -c is helpful for first time users.

[lance]

@nainaz there are a couple of overlapping issues related to this. I closed one AND created one of them yesterday. :stuck_out_tongue:

https://github.com/knative-sandbox/kn-plugin-func/issues/768 was created in favor of https://github.com/knative-sandbox/kn-plugin-func/issues/635, which I closed. And I think we should consider closing this one as well. wdyt?

[omerbensaadon]

Glad y'all are finally getting around to some of this stuff!!

I think this one is actually quite important for onboarding new users. IMO, we want to keep devs "hacking" for as long as possible before they have to reference any documentation.

This feature (combined with #768) would make it so users wouldn't need to know anything but "func create" in their first experience.

[lance]

To be clear... If a user types func create with no flags or other parameters, the default should be to enter confirm mode as though they had typed func create -c. But anything other than a bare func create should behave as it does today?

For example for the two scenarios below are behaving as desired today.

❯ kn-func create -t events
Error: Required flag "language" not set.
Available language runtimes are:
  go
  node
  nodejs
  python
  quarkus
  ruby
  rust
  springboot
  typescript

And

❯ kn-func create -l node
Created node Function in /home/lanceball/src/github.com/boson-project/buildpacks/foo

I like this - makes sense. Apologies for not fully grasping the ask earlier.

[nainaz]

Yes. That is the ask :) No worries. Thank you, -N

On Thu, 20 Jan 2022 at 17:49, Lance Ball @.***> wrote:

To be clear... If a user types func create with no flags or other parameters, the default should be to enter confirm mode as though they had typed func create -c. But anything other than a bare func create should behave as it does today?

For example for the two scenarios below are behaving as desired today.

❯ kn-func create -t events

Error: Required flag "language" not set.

Available language runtimes are:

go

node

nodejs

python

quarkus

ruby

rust

springboot

typescript

And

❯ kn-func create -l node

Created node Function in /home/lanceball/src/github.com/boson-project/buildpacks/foo

I like this - makes sense. Apologies for not fully grasping the ask earlier.

— Reply to this email directly, view it on GitHub https://github.com/knative-sandbox/kn-plugin-func/issues/573#issuecomment-1017995470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISZCFDW5S7WFJWVZTT2VKTUXCGQ3ANCNFSM5FZAI3HA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[lance]

/kind MVP

[knative-prow-robot]

@lance: The label(s) kind/mvp cannot be applied, because the repository doesn't have them.

In response to this:

/kind MVP

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lance]

This can be deferred to post 1.0

[nainaz]

I would argue that this is going to be first interaction users would have. And the more intuitive, polished, and intuitive it could be the better. I would put this as MVP for 1.0

[lance]

I would argue that this is going to be first interaction users would have. And the more intuitive, polished, and intuitive it could be the better. I would put this as MVP for 1.0

I understand your concern, but think that a more compelling case needs to be made.

To be clear, the use case you are describing is that, when a user types func create with no parameters, then just dump them into an interactive prompt instead of providing some helpful text. Here is the experience today.

❯ func create
Error: Required flag "language" not set.
Available language runtimes are:
  go
  node
  python
  quarkus
  rust
  springboot
  typescript

~/demo/first
❯ func create -l node
Created node Function in /Users/lball/demo/first

This is not a terrible experience in my opinion. My take is that this issue is a nice to have feature but can't be considered a blocker for 1.0. I'm just not sure it makes sense to prioritize a nice to have feature, geared at only brand new users, and only for the first time they use the tool, based on a handful of first time user experience interviews conducted well before many of the other UX improvements have landed, at the expense of other, more important and generally useful things like on cluster build, dynamic templates, and s2i.

I agree that we want the UX to be as smooth as possible. I just don't agree that this particular behavior is a requirement for 1.0. :)

[nainaz]

I agree that cluster build, global configuration and s2i are more important feature. I would still like this "mistake" from users turned into experience. If we all think that it is "nice to have" I will stop pushing. :) :)

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[nainaz]

@Mauricio Salatino @.***> adding you to the issue that is around create command for putting this as reference on new issue. Thank you, -N

On Wed, 6 Jul 2022 at 21:34, github-actions[bot] @.***> wrote:

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

— Reply to this email directly, view it on GitHub https://github.com/knative-sandbox/kn-plugin-func/issues/573#issuecomment-1176943883, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISZCFHLHM72ZNAMZN7IHOLVSYX2HANCNFSM5FZAI3HA . You are receiving this because you were mentioned.Message ID: @.***>

[lance]

/remove-lifecycle stale

[lance]

Should be resolved in https://github.com/knative-sandbox/kn-plugin-func/issues/901

[grafvonb]

@lkingland Are you working on it? If not, I can take over.

[grafvonb]

/assign @grafvonb

[lkingland]

@lkingland Are you working on it? If not, I can take over.

Yes

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[zroubalik]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.