We should decided whether functions cli should be a kn plugin - kn func or a standalone cli - func

[zroubalik]

At the moment func could be a standalone CLI or a kn plugin, in the long term we should decide on which approach we would like to promote. The current situation is confusing.

I will try to summarize pros and cons for both approaches

Standalone func

Pros

• kn and func are conceptually different, kn mainly operates resources on a cluster (think of kubectl), but the UX of func is mainly built around local source code and manifests (there are a few exceptions though, func list,...)
• A separate CLI might give Knative Functions a better "visibility" or marketing
• It is faster to type func than kn func
• Each CLI is in a different phase of development, kn is relatively stable but func is not - each CLI can maintain it's release cadence

Cons

• Users need to download, install and use yet another CLI
• User experience might suffer from not unified look&feel of func and kn (parameters, output, formating,...)
• kn and func might have similar commands for the same funcitonality (kn event vs func invoke,...)
• How should we tackle things that are beyond just Functions? ie. Functions/KServices orchestrations, events binding? Should we implement it both in kn and func or instruct users to use each CLI for a different task?

What are the next steps if we choose this approach?

• Make clear distinction in docs, website,...
• At least try to coordinate on a similar UX and Look&Feel

Plugin - kn func

Pros

• Users have a single CLI for all stuff related to Serverless (this is usually the standard apporach in this area - Azure, AWS,...CLIs
• It should be less complicated to install this thing
• Possibility to unify UX and merge overlapping commands
• kn is the ultimate tool, user don't have to switch contexts and commong things (events binding, orchestration) is done from a single CLI

Cons

• typing kn func is not so fast as just func
• different phase of development of kn and fun`, there is a different need for release cadence

What are the next steps if we choose this approach?

• upstream kn should already contain func plugin by default
• Look&Feel needs to be unified
• similar commands merged
• agree on naming convetion etc.
• existing flags/arguments needs to be sync between, so users have predictable UX

[pierDipi]

IMHO, second option, because having to deal with yet another CLI is not a good UX, in particular all the "next steps if we choose this approach" sound very good ways to improve the UX overall.

Just for reference, I will link this comment knative/operator#914 (comment), which could be another data point to make a decision; the second option is not completely solving that problem but I guess having both available together is a more compelling reason to adopt both.

[AlyIbrahim]

Why not keep both options !?

Adding func as a kn plugin will help with the problem of not dealing with 2 different CLIs while on the other hand from the developers side, func should be enough for them if functions is all what they want to develop.

[lkingland]

We can have the "pro"s of both by continuing with our current path of allowing func to be used standalone or as a plugin. The unix philosophy, as is often cited stands, is to not create monoliths.

As func grows to encapsulate an entire developer workflow, it will become more and more clear that kn and func provide a unique experience, and unique tools.

To ease confusion, I would love for there to be a simple way to install func as a kn plugin by default. Could an installer look for this situation and symlink kn-func -> func so that there is zero friction.

[github-actions]

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.

[rhuss]

Not sure if this discussion has just been abandoned or has been resolved (if so, I don't see the solution though), but IMO its much more than just about the technique how to invoke func (whether standlone or via kn) but much more about semantics and/or user experience.

If used as a plugin ...

• should the user use kn event send or kn func invoke to send events to a cluster ?
• Should a trigger be created via kn trigger create or potentially via kn func subscribe ? Interestingly, there is also a kn subscription command which deals about channels, but not triggers. Slightly confusing, I would say :)

I don't mind much if we have the same functionality to be called on different levels (even if this agains the mentioned Unix philosophy and more like Perl's TMTOWTDI (There are many ways to do it)), but we should avoid to have different semantics at all cost (e.g. how to specify brokers or sinks in options.