Updated Proposal: CLI plugins

[tjar...@pivotallabs.com]

Hey all,

The CLI team has been pondering how plugins might work for v6. We had a fairly successful github thread a month ago, as well as some discussions here on vcap dev. We recently took some time to discuss the pros and cons of the various approaches. I've distilled this discussion into a convenient list of priorities and proposed features / solutions so that we can share our plan moving forward. 

• any executable can be a plugin (i.e.: written in any language)
• plugins can provide a new command for users to invoke
• plugins must provide help, usage, etc
• plugins cannot override any of the blessed, internal commands
• plugins will be invoked by the CLI shelling out an executable named 'cf-$PLUGIN', or something similar
• plugins will be able to invoke the CLI
• existing commands should be decomposed so plugin authors can use them more effectively
• plugins will not be forced to run on all supported architectures / platforms
• plugins can opt-in to having flags parsed by the CLI (similar to existing flags)
• some existing commands will be converted to plugins, to help drive this effort
• plugins should have an API to print messages to the user, to ensure consistent UX
• there will be some sort of machine readable output in the CLI
• no attempt at securing plugins will be made (since you're effectively executing untrusted code)
• pre/post hooks (with extreme limitations and user warning) are a stretch goal

Our next steps are to start writing stories and slating this work for our upcoming iterations, so if you feel strongly that we're making a mistake, please let us know. If you look in our tracker project, you may even see some of these stories coming together now.

As always, thoughts, concerns, rants, and ideas are all welcome.

Thanks!

-Tim, Karen, Dan, Anand, Foley and Scott {{The CLI team}}

[Doug Davis]

Nice - I particularly like:

• plugins can opt-in to having flags parsed by the CLI (similar to existing flags)

• plugins should have an API to print messages to the user, to ensure consistent UX

to push for consistency and ease of plug-in creation!

Can you elaborate on?
 - existing commands should be decomposed so plugin authors can use them more effectively


thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  d...@us.ibm.com
The more I'm around some people, the more I like my dog.

tjarratt---04/23/2014 05:06:18 PM---Hey all, The CLI team has been pondering how plugins might work for v6. We had a

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[tjar...@pivotallabs.com]

Can you elaborate on?
 - existing commands should be decomposed so plugin authors can use them more effectively

Absolutely! We believe that some commands (eg: 'cf push') are so large that it would be hard for plugin authors to use them effectively because they may want to insert custom behavior somewhere in the middle. If we decompose some of these large commands into smaller subcommands, it should be easier for plugin authors to write plugins that perform actions in the middle of 'cf push', without needing hooks immediately.