openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Mitchell <moose...@gmail.com>
Subject Re: OpenWhisk shell tool
Date Fri, 04 Aug 2017 18:22:46 GMT
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 <tnorris@adobe.com.invalid>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message