confusing messages when trying to install from non-existent package

[porridge]

What happened:

Tried to install an operator from a tarball which does not exist. Received a confusing message which:

• does not contain the string no such file
• contains the mistyped filename 3 times
• does not contain a colon before the word getting
• says something about resolving and index files. These are package repository implementation details opaque to a casual user and are just confusing. I bet a typical user would start to check their DNS setup when after reading such message...

$ kubectl kudo install filename-with-typo.tgz
Error: failed to resolve operator package for: filename-with-typo.tgz getting filename-with-typo.tgz in index file: no operator found for: filename-with-typo.tgz
$ kubectl kudo install ./filename-with-typo.tgz
Error: failed to resolve operator package for: ./filename-with-typo.tgz getting ./filename-with-typo.tgz in index file: no operator found for: ./filename-with-typo.tgz

What you expected to happen:

$ kubectl kudo install filename-with-typo.tgz
Error: failed to find operator package for: filename-with-typo.tgz: no such file or directory in local filesystem, and no such operator in configured package repositories

How to reproduce it (as minimally and precisely as possible):

See above.

Anything else we need to know?:

Some additional thoughts:

I see people struggle with this message in different use cases (tried to get a package from the repo, but happened to have a directory named the same locally; tried to install from a local tarball but had a typo in the name, etc..) and every time the long confusing message made them give up.

Is a dot even allowed in operator names? If not, then the CLI should be able to deduce that this not a name that could possibly exist in a repository and not even look it up there.

The logic for finding an operator is moderately complex. It may be that it is impossible to summarize a failure of such workflow in one line, in a way that is comprehensible to an end-user. Perhaps it would be better to echo the progress as it happens after all, even if that would mean extra verbosity.

Environment:

• Kubernetes version (use kubectl version):
• Kudo version (use kubectl kudo version): KUDO Version: version.Info{GitVersion:"0.15.0", GitCommit:"f58547c5", BuildDate:"2020-07-09T20:48:15Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"linux/amd64"} - the experience is the same when using current tip of main
• Operator:
• operatorVersion:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others: