openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Re: OpenWhisk shell tool
Date Fri, 04 Aug 2017 16:23:12 GMT
Some thoughts on this: I think one thing that would make this less confusing is introducing
a REPL to the wsk CLI (or a wrapper of it) instead of introducing REPL as “a desktop application
with a gui”. I like the gui, but I also think it may be adding a layer of confusion.

Similarly, it should be carefully considered how commands can be consistent between REPL and
non-REPL usage, e.g. for related CLI auth discussion, it would be great if:
wsk auth
Had the same effect as:
REPL: auth

The difference being that wsk auth would store credentials to disk for use at next wsk command
run, and REPL: auth would store credentials for the length of the session only. In addition,
the REPL may be able to conveniently pop up an auth dialog, where the CLI may have to ask
you to load a url, but the end result would be the same.

From there the notion of “REPL has a special language in addition to the CLI commands”
is something easier (at least for me) to get behind, as long as things that are not purely
session-based are added to the CLI as well (like auth flavored commands). 

Thanks for starting this tool, I think its useful and look forward to watching it progress!

Tyson




> On Aug 4, 2017, at 8:59 AM, Nick Mitchell <moosevan@gmail.com> wrote:
> 
> With the shell, one would issue `last`. Or `last foo`. With a REPL, we have
> the luxury of a flexible command structure that can be tailored to the task
> at hand.
> 
> And, once you are looking at that activation, you can drill down (eg to
> tree view of the sequence), or reinvoke (we can remember the input), or
> reinvoke with new args, or add this action to a sequence now that you know
> it works (append to myseq).
> 
> These are all plugins, so new ideas can appear as shell commands in a
> matter of minutes.
> 
> On Aug 4, 2017 11:49, "Rodric Rabbah" <rodric@gmail.com> wrote:
> 
>> This is a very useful discussion - thank you Rob for starting it. We both
>> want and need this kind of feedback!
>> 
>> One of the observations that you noted wrt to the shell is that it has "its
>> own language". Indeed there is a language here, in the same way that the
>> wsk CLI already offers a language for serverless programming using
>> OpenWhisk. When the language of the CLI is limiting, what do we do as
>> developers? I posit that we layer new languages on top --- my favorite
>> example is "give me the last activation". At one point I polled for how
>> many bash aliases the community has come up with for this feature! Recently
>> the wsk CLI added `wsk activation get --last`. That's still too verbose and
>> I continue to use my local alias for this command and I expect others will
>> too. More concretely, it's too verbose when I'm developing, iterating, and
>> debugging.
>> 
>> In the same way, I've seen developers share bash scripts for automating
>> other tasks that the current wsk CLI (or really any client) doesn't yet
>> support. For example: deleting all assets in a namespace, or a package.
>> These are features I expect will eventually end up in the wsk CLI. But the
>> gate for rapidly experimenting with new aliases, plugins, features is too
>> narrow today.
>> 
>> The "openwhisk shell" is a way of normalizing the programming experience
>> for serverless - it does subsume the CLI in that the wsk commands should
>> work inside it, but also extends the capabilities to add more syntactic
>> convenience and make a workflow more fluid - some of these may not be
>> readily possible or practical in a terminal. One of the benefits that I've
>> experienced directly is that it makes the iterative programming experience
>> and development for serverless more agile and fluid.
>> 
>> To me, this is independent of the question of scripting for deployment,
>> continuous integration, and delivery and hence the context for my "old
>> school" comment - the shell can export a bash script for you, or other
>> artifacts like a serverless framework manifest, for managing a deployment
>> (as examples).
>> 
>> -r
>> 

Mime
View raw message