openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Re: OpenWhisk shell tool
Date Fri, 04 Aug 2017 18:46:26 GMT
I didn’t get that it can be invoked from a shell in a REPL style, thanks - is this possible
with the current downloads? 

I appreciate the value of the UI (looks great btw!) - its just not clear how to do the 'scripted
execution’ parts?

> On Aug 4, 2017, at 11:22 AM, Nick Mitchell <> wrote:
> thanks tyson!
> the tool can indeed be used in a purely bashy way, if that's helpful. so
> e.g., the following works, assuming for a second that we call the Shell
> `wsker` for the purpose of this email:
> wsker activation get foo
> wsker action invoke foo
> wsker activation get xxxx
> these look familiar, i think? hehe, what i'm getting at is that the command
> set overlaps! and you can issue one-off commands to the Shell directly from
> bash, if you'd like; or in a bundle via `wsker script.txt`
> i propose that you will quickly discover the value of having the electron
> app, including:
> 1) your command history is specific to openwhisk, so you don't have to
> arrow up past non-whisk commands
> 2) the command set is richer
> 3) you get visuals for the common and important data
> 4) no more copy-paste of that xxxx part of wsk activation get!
> 5) an app to itself, with its own icon and one that can be separately
> minimized/maximized, or pinned to desktops
> nick
> @starpit
> On Fri, Aug 4, 2017 at 12:23 PM, Tyson Norris <>
> wrote:
>> 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 <> 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" <> 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

View raw message