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 > >> > >
