You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Rob Allen <ro...@akrabat.com> on 2017/08/04 13:54:14 UTC
OpenWhisk shell tool
Hi,
I've been watching the meeting from yesterday and have some questions about the shell. I'll put them all on separate lines to make it easier for people to reply :)
This new shell thing seems to be its own app. How accessible is it for people who can't use a mouse and need to drive it via keyboard only?
It looks like an interactive thing like Swift Playgrounds with a timeline history. I'm not clear if that that history list on the left is interactive or if you can edit any of them arbitrarily and re-run them?
I can't work out how version control works with this tool. Do we save documents of the timeline that we can reload? If we do, is it a text based format for the saved file?
How would this work for production development with a team?
It looks like it the shell has its own language, Is it documented? I'm concerned that we're inventing a whole new language off the cuff...
Related, how stable is this shell language? If someone writes a script in OWShell, it's likely to continue to work in the future? Are we going to get BC breaks in scripts that people publish (if they can publish them)?
It is JS only? i.e. does it exclude people like me who don't understand JS and write their actions in the other languages?
I was a bit concerned to hear someone call the export to wsk format as "old school" That implies that there's a plan to deprecate the current CLI and that this OWShell is the new way to write all OpenWhisk applications. Is this correct and if so, is OWShell completely scriptable via bash and Windows PowerShell so that it can be automated? It's neat that you can paste into OWShell, but that's hard to do in CI environment.
I'm a bit confused as to the status of this tool. There was mention of a vague hope to OpenSource it, but it didn't sound very concrete or important to the speaker. Is it proprietary to IBM? Will it work with other installations of OpenWhisk?
I haven't played with it yet, so maybe these all become obvious in when it's used. More tooling around OpenWhisk is good, so I don't want to sound critical. I suppose my main concerns are that this means that OpenWhisk is going even more heavily towards being a JavaScript only platform and that non-interactive deployments of OpenWhisk applications are being discouraged.
Regards,
Rob.
Re: OpenWhisk shell tool
Posted by Michael M Behrendt <Mi...@de.ibm.com>.
> I was a bit concerned to hear someone call the export to wsk format as
"old
> school" That implies that there's a plan to deprecate the current CLI
and
> that this OWShell is the new way to write all OpenWhisk applications. Is
> this correct and if so, is OWShell completely scriptable via bash and
> Windows PowerShell so that it can be automated? It's neat that you can
> paste into OWShell, but that's hard to do in CI environment.
>
let me try to clarify that, eliminating any room for misinterpretation:
I think 'old school' was a poor choice of words. There is *NO* intent to
deprecate the current cli -- it's absolutely strategic. The OW shell tool
is at the moment an exploratory effort by the IBM research team to explore
complementary user experiences, but this doesn't impact in any way the
role of the 'standard' cli.
From: Nick Mitchell <mo...@gmail.com>
To: dev@openwhisk.apache.org
Date: 08/04/2017 04:25 PM
Subject: Re: OpenWhisk shell tool
Thanks rob for the great questions!
> This new shell thing seems to be its own app. How accessible is it for
> people who can't use a mouse and need to drive it via keyboard only?
>
>
it can be used entirely without a mouse. for example, to open and close
the
sidecar, use the Escape key. history can be navigated either with arrow
keys, or emacs cursor navigation (Ctrl+P, ...).
> It looks like an interactive thing like Swift Playgrounds with a
timeline
> history. I'm not clear if that that history list on the left is
interactive
> or if you can edit any of them arbitrarily and re-run them?
>
>
there is a `history` command that lets you explore and re-execute elements
of history, as you would with e.g. bash.
> I can't work out how version control works with this tool. Do we save
> documents of the timeline that we can reload? If we do, is it a text
based
> format for the saved file?
>
>
the Shell does support multi-line pasting. it also has a `run` command
that
allows you to execute a sequence of Shell commands stored in a file. it
does not as of yet have an `export` command, though there have been
several
thoughts in this direction!
for example, to generate the docs page ibm.biz/wskshell, we have a
`demo.wsk` file that contains the handful of commands necessary to
generate
the entire site.
the demo.wsk file sits in a repo, under SCM. this is just one example of
how we're doing things. i'm sure we'll find more and better ways as we go!
> How would this work for production development with a team?
>
>
truthfully, the Shell is so new that we don't have data points to give you
a good answer on this one. can you help me, by clarifying what you think
the production requirements are? i have answers, but would like to make
sure i'm answering the right questions :) thanks!
> It looks like it the shell has its own language, Is it documented? I'm
> concerned that we're inventing a whole new language off the cuff...
>
>
the Shell is exactly like the `wsk` tool, in that there are commands. yes,
it is a langauge, of sorts, but they really are just commands. the Shell
supports all of the `wsk` commands. it augments them either to add
functions `wsk` does not have, or to offer an alternative syntax that is
(perhaps) more appealing.
e.g. a -> b -> c can be used to construct sequences, and the `let` command
can be used to name the sequence... but you can also use `wsk action
create
--sequence a,b,c` if that form is more comfortable to you!
> Related, how stable is this shell language? If someone writes a script
in
> OWShell, it's likely to continue to work in the future? Are we going to
get
> BC breaks in scripts that people publish (if they can publish them)?
>
>
it is early, admittedly, so there are no guarantees. in the earlier days
of
OpenWhisk, i recall my scripts breaking every other day as `wsk` and the
API stabilized... however, we have 689 tests at this point, so i would
consider things to be fairly stable at this point.
once (soon!) we open source it, then alternative command structures can
win
by vote/merit, etc.!
It is JS only? i.e. does it exclude people like me who don't understand JS
> and write their actions in the other languages?
>
>
there is nothing javascript-specific about the Shell. the `let` syntax
harkens to javascript, but it is purely sugar. we could quite easily add a
`def` syntax for action creation, etc. the command structure is populated
entirely via a hierarchical plugin architecture. more details on that
soon.
I was a bit concerned to hear someone call the export to wsk format as
"old
> school" That implies that there's a plan to deprecate the current CLI
and
> that this OWShell is the new way to write all OpenWhisk applications. Is
> this correct and if so, is OWShell completely scriptable via bash and
> Windows PowerShell so that it can be automated? It's neat that you can
> paste into OWShell, but that's hard to do in CI environment.
>
the Shell is indeed scriptable, either via `run` from within the shell, or
directly from bash.
as to the future, ...., above my pay grade, but... my goal in making the
Shell was to foster this very kind of discussion: what is the best way to
program the serverless cloud? in my experience, this requires a REPL, and
one with concise syntax, so that i can quickly and iteratively refine my
understanding of the world. i don't want to write bash scripts for tasks
that are common! bake those into a richer command structure, so that we,
ALL of us, can benefit from the group's knowledge.
the `let` command is an example of this, as is the `every` command.
creating actions is more than just `wsk action create`. there are needs
for
inline/anonymous functions for simple schema aligners... periodic rules
are
quite syntactically complex with `wsk`. let's capture these common cases!
this is a main point of the Shell.
beyond richer commands, i feel that cloud programming also requires some
visuals, because so much of the data these days is complex JSON that is a
real pain to parse in one's head. and monitoring logs and activations are
tasks that are quite well suited to visualizations. having to task switch
into a different tool, with its own login/session systems... breaks my
flow
for what should be a 10 second side task. let's optimize these flows!
> I'm a bit confused as to the status of this tool. There was mention of a
> vague hope to OpenSource it, but it didn't sound very concrete or
important
> to the speaker. Is it proprietary to IBM? Will it work with other
> installations of OpenWhisk?
>
>
we will open source the core of this quite soon.
Re: OpenWhisk shell tool
Posted by Raymond Camden <ra...@gmail.com>.
On Fri, Aug 4, 2017 at 9:38 AM, Nick Mitchell <mo...@gmail.com> wrote:
>> On Fri, Aug 4, 2017 at 9:25 AM, Nick Mitchell <mo...@gmail.com> wrote:
>>
> fair points, raymond!
>
> here is the current documentation story, which admittedly needs work.
>
> 1) there is a `help` command, which will show you the commands available in
> your current context. e.g. if you have selected an action, then the `set`
> command will show up in the help list. `set` can be used to CRUD
> parameters. e.g. `set x=1`.
>
> 2) we have this page: https://ibm.biz/wskshell which, in addition to some
> videos, has hexagons that introduce the command set. in addition to
> introducing the commands, there are a few "scenario" examples, that show
> how to use those commands for larger tasks. for example, there is a
> scenario page on creating a web page.
This is helpful, thank you Nick!
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
On Fri, Aug 4, 2017 at 10:32 AM, Raymond Camden <ra...@gmail.com>
wrote:
> On Fri, Aug 4, 2017 at 9:25 AM, Nick Mitchell <mo...@gmail.com> wrote:
> >> It looks like it the shell has its own language, Is it documented? I'm
> >> concerned that we're inventing a whole new language off the cuff...
> >>
> >>
> > the Shell is exactly like the `wsk` tool, in that there are commands.
> yes,
> > it is a langauge, of sorts, but they really are just commands. the Shell
> > supports all of the `wsk` commands. it augments them either to add
> > functions `wsk` does not have, or to offer an alternative syntax that is
> > (perhaps) more appealing.
>
> Can I just say though - every demo I've seen so far has confused the
> heck of out me. You didn't really answer the question on
> documentation, and I think we *really* need something there to make it
> a bit more usable. (If it already exists, cool.) It looks incredibly
> cool, but the syntax is so... I don't know... cool (grin), that I
> can't even understand it. What are the plans to explain the basics?
> Again, not the wsk commands, I get those, but in your tool it looks
> alien to me! (And I don't mean that as a negative, it looks super
> powerful, just need help grokking it).
>
>
fair points, raymond!
here is the current documentation story, which admittedly needs work.
1) there is a `help` command, which will show you the commands available in
your current context. e.g. if you have selected an action, then the `set`
command will show up in the help list. `set` can be used to CRUD
parameters. e.g. `set x=1`.
2) we have this page: https://ibm.biz/wskshell which, in addition to some
videos, has hexagons that introduce the command set. in addition to
introducing the commands, there are a few "scenario" examples, that show
how to use those commands for larger tasks. for example, there is a
scenario page on creating a web page.
more is needed, and i hope you all can help me prioritize the docs tasks.
please feel free to rudely ask for docs where they don't exist!
nick
Re: OpenWhisk shell tool
Posted by Raymond Camden <ra...@gmail.com>.
On Fri, Aug 4, 2017 at 9:25 AM, Nick Mitchell <mo...@gmail.com> wrote:
>> It looks like it the shell has its own language, Is it documented? I'm
>> concerned that we're inventing a whole new language off the cuff...
>>
>>
> the Shell is exactly like the `wsk` tool, in that there are commands. yes,
> it is a langauge, of sorts, but they really are just commands. the Shell
> supports all of the `wsk` commands. it augments them either to add
> functions `wsk` does not have, or to offer an alternative syntax that is
> (perhaps) more appealing.
Can I just say though - every demo I've seen so far has confused the
heck of out me. You didn't really answer the question on
documentation, and I think we *really* need something there to make it
a bit more usable. (If it already exists, cool.) It looks incredibly
cool, but the syntax is so... I don't know... cool (grin), that I
can't even understand it. What are the plans to explain the basics?
Again, not the wsk commands, I get those, but in your tool it looks
alien to me! (And I don't mean that as a negative, it looks super
powerful, just need help grokking it).
--
===========================================================================
Raymond Camden, Developer Advocate at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
oh, i should've answered the last question better. let's try again:
I'm a bit confused as to the status of this tool. There was mention of a
> vague hope to OpenSource it, but it didn't sound very concrete or important
> to the speaker. Is it proprietary to IBM? Will it work with other
> installations of OpenWhisk?
yes, open source coming soon. and: we have indeed used it with non-IBM
openwhisk installations!
the `host` command can be used, from within the Shell, to swap hosts.
`host` accepts a hostname, and it also has a few shorthands. e.g. `host
mac` will direct the Shell to the standard local docker-machine IP:port;
`host local` will direct it to the standard local docker IP:host; `host
us-south` and `host bluemix`, etc. are short-hands for some of the IBM
standard API hosts.
once you've chosen a host, `auth` command can be used, from within the
Shell, to swap or add new auth keys. e.g. `auth add xxxx` or `auth switch
namespace2`
for users of IBM OpenWhisk, there is a `bluemix` tree of commands; e.g.
`bluemix login`, which accepts the standard `bx login` arguments, can be
used to acquire an auth key for a given bluemix org and space; and `bluemix
cost` will tell you the approximate cost of your recent activations.
nick
@starpit
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
Thanks rob for the great questions!
> This new shell thing seems to be its own app. How accessible is it for
> people who can't use a mouse and need to drive it via keyboard only?
>
>
it can be used entirely without a mouse. for example, to open and close the
sidecar, use the Escape key. history can be navigated either with arrow
keys, or emacs cursor navigation (Ctrl+P, ...).
> It looks like an interactive thing like Swift Playgrounds with a timeline
> history. I'm not clear if that that history list on the left is interactive
> or if you can edit any of them arbitrarily and re-run them?
>
>
there is a `history` command that lets you explore and re-execute elements
of history, as you would with e.g. bash.
> I can't work out how version control works with this tool. Do we save
> documents of the timeline that we can reload? If we do, is it a text based
> format for the saved file?
>
>
the Shell does support multi-line pasting. it also has a `run` command that
allows you to execute a sequence of Shell commands stored in a file. it
does not as of yet have an `export` command, though there have been several
thoughts in this direction!
for example, to generate the docs page ibm.biz/wskshell, we have a
`demo.wsk` file that contains the handful of commands necessary to generate
the entire site.
the demo.wsk file sits in a repo, under SCM. this is just one example of
how we're doing things. i'm sure we'll find more and better ways as we go!
> How would this work for production development with a team?
>
>
truthfully, the Shell is so new that we don't have data points to give you
a good answer on this one. can you help me, by clarifying what you think
the production requirements are? i have answers, but would like to make
sure i'm answering the right questions :) thanks!
> It looks like it the shell has its own language, Is it documented? I'm
> concerned that we're inventing a whole new language off the cuff...
>
>
the Shell is exactly like the `wsk` tool, in that there are commands. yes,
it is a langauge, of sorts, but they really are just commands. the Shell
supports all of the `wsk` commands. it augments them either to add
functions `wsk` does not have, or to offer an alternative syntax that is
(perhaps) more appealing.
e.g. a -> b -> c can be used to construct sequences, and the `let` command
can be used to name the sequence... but you can also use `wsk action create
--sequence a,b,c` if that form is more comfortable to you!
> Related, how stable is this shell language? If someone writes a script in
> OWShell, it's likely to continue to work in the future? Are we going to get
> BC breaks in scripts that people publish (if they can publish them)?
>
>
it is early, admittedly, so there are no guarantees. in the earlier days of
OpenWhisk, i recall my scripts breaking every other day as `wsk` and the
API stabilized... however, we have 689 tests at this point, so i would
consider things to be fairly stable at this point.
once (soon!) we open source it, then alternative command structures can win
by vote/merit, etc.!
It is JS only? i.e. does it exclude people like me who don't understand JS
> and write their actions in the other languages?
>
>
there is nothing javascript-specific about the Shell. the `let` syntax
harkens to javascript, but it is purely sugar. we could quite easily add a
`def` syntax for action creation, etc. the command structure is populated
entirely via a hierarchical plugin architecture. more details on that soon.
I was a bit concerned to hear someone call the export to wsk format as "old
> school" That implies that there's a plan to deprecate the current CLI and
> that this OWShell is the new way to write all OpenWhisk applications. Is
> this correct and if so, is OWShell completely scriptable via bash and
> Windows PowerShell so that it can be automated? It's neat that you can
> paste into OWShell, but that's hard to do in CI environment.
>
the Shell is indeed scriptable, either via `run` from within the shell, or
directly from bash.
as to the future, ...., above my pay grade, but... my goal in making the
Shell was to foster this very kind of discussion: what is the best way to
program the serverless cloud? in my experience, this requires a REPL, and
one with concise syntax, so that i can quickly and iteratively refine my
understanding of the world. i don't want to write bash scripts for tasks
that are common! bake those into a richer command structure, so that we,
ALL of us, can benefit from the group's knowledge.
the `let` command is an example of this, as is the `every` command.
creating actions is more than just `wsk action create`. there are needs for
inline/anonymous functions for simple schema aligners... periodic rules are
quite syntactically complex with `wsk`. let's capture these common cases!
this is a main point of the Shell.
beyond richer commands, i feel that cloud programming also requires some
visuals, because so much of the data these days is complex JSON that is a
real pain to parse in one's head. and monitoring logs and activations are
tasks that are quite well suited to visualizations. having to task switch
into a different tool, with its own login/session systems... breaks my flow
for what should be a 10 second side task. let's optimize these flows!
> I'm a bit confused as to the status of this tool. There was mention of a
> vague hope to OpenSource it, but it didn't sound very concrete or important
> to the speaker. Is it proprietary to IBM? Will it work with other
> installations of OpenWhisk?
>
>
we will open source the core of this quite soon.
Re: OpenWhisk shell tool
Posted by Carlos Santana <cs...@gmail.com>.
This is a great discussion !
I agree with Rodric when he said that there is a gap in tooling in the
serverless/FaaS world
This gap provides attractions to come with many tools and ideas on how to
satisfy many needs, education, experimentation, developing, composition,
re-use, debugging, testing, deploying, testing, and monitoring.
I can see many tools being created even if they target the same need and
even if there is overlap, that's OK, it takes time for adoption and
convention to have a large pool of people agreeing on what's the best tool
for the job, so some tools will continue forward and other tools would just
stay as good experiments or merge into other tools.
For OWShell, if I were to name it I would name it something along the
lines as OWWorksheet or OWPlayground or OWReplUI not use the "Shell" and
avoid confusion with the current OW CLI/Shell. Maybe is not confusing, but
it's good to clarify that the WSK CLI is very stable client of the OW REST
API and will NOT be replace, it does it's job for unattended deployments in
CI/CD in our production pipeline, also other users already using it today
and OK with it.
This OWShell UI, It has a feeling like Scala Worksheet [1], Swift
Playgrounds [2] mixed with Repls like Scala Repl and [3] NodeJS Repl
There are lot of useful use cases I could see my self pull from this tool,
primarily as experiment and teaching tool for OpenWhisk.
I can see my self giving a talk at a conference or meetup which I typically
only have 45 minutes to show the concepts and values of OpenWhisk, I can
quickly show demos and iterate fast over different ideas, and answer
questions live with the tool.
Similar use cases are along the line of Swift PlayGrounds allows me to have
some visual results on the code next to it, having both side by side,
clicks in people's head on cause and effect, very powerful when getting
started into a platform/language
The REPL aspect it let's me validate ideas on how I think it should or
would work and how actually works of behaves.
One thing is writing a single function with inputs and outputs, but another
more tricky is when I want to use that function in a sequence, or call it
from a trigger, and do a breakpoint.
I like that the idea of exporting / saving session or commands, this allows
me to share with others, or save and use as a starting point when getting
started for a new application with my current workflow of using a project
directory stored in scm (i.e. git) next to my current CI/CD scripts that
leverages the WSK CLI.
This is similar to some tool I found Scastie [4] allows you to play with
Scala code on the Browser and then allow export/download a project I can
take into my git repo and continue from there.
I have being developing tools for a while, I tend to forget that developers
using this tools, they want to use their time working on their code and not
tuning tools, the tools should allow them to do their work and get out of
their way. If they find a tool that would get the compile/deploy task done
so they can continue working on their code they would be happy with that.
Tools are cool and nice to have, but developer's spent most of their time
in the business logic code working with the language at hand.
I tend to spend more time deleting, and recreating apps with this tools,
because I develop the tools, and show demos using this tools, but for my
own apps, I write "deploy.sh" once and call to be called from
Travis/Jenkins and that's it I don't want to touch it again, only when
adding a new file to the project :-)
-- Carlos
[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started
[2] https://developer.apple.com/swift/playgrounds
[3] https://nodejs.org/api/repl.html
[4] https://scastie.scala-lang.org
On Fri, Aug 4, 2017 at 2:49 PM Nick Mitchell <mo...@gmail.com> wrote:
> 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 <tn...@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 <mo...@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 <mo...@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" <ro...@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
> > >>>>
> > >>
> > >>
> >
> >
>
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
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 <tn...@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 <mo...@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 <mo...@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" <ro...@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
> >>>>
> >>
> >>
>
>
Re: OpenWhisk shell tool
Posted by Tyson Norris <tn...@adobe.com.INVALID>.
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 <mo...@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 <tn...@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 <mo...@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" <ro...@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
>>>>
>>
>>
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
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 <tn...@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 <mo...@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" <ro...@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
> >>
>
>
Re: OpenWhisk shell tool
Posted by Tyson Norris <tn...@adobe.com.INVALID>.
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 <mo...@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" <ro...@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
>>
Re: OpenWhisk shell tool
Posted by Nick Mitchell <mo...@gmail.com>.
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" <ro...@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
>
Re: OpenWhisk shell tool
Posted by Rodric Rabbah <ro...@gmail.com>.
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