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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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" <[email protected]> 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 >>>> >> >>
