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:49:21 GMT
the current release (1.1.1) does not yet expose the bashy variant. i'll do
that for 1.2.0, it's ready to go, i just haven't had a chance to include it
in the dist bundles.

for 1.1.1, you can use the `run` command from within the Shell. this will
execute a sequence of Shell commands from a file. prior to 1.1.1, we didn't
expose the `run` command even in the Shell.

we're getting there, especially with all of the great feedback we're
getting. keep it coming!!

nick
@starpit


On Fri, Aug 4, 2017 at 2:46 PM, Tyson Norris <tnorris@adobe.com.invalid>
wrote:

> 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?
> Thanks
> Tyson
>
> > On Aug 4, 2017, at 11:22 AM, Nick Mitchell <moosevan@gmail.com> 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 <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