On Tue, May 1, 2012 at 11:49 AM, Adam Spiers <aspi...@suse.com> wrote: > Doug Hellmann (doug.hellm...@dreamhost.com) wrote: >> On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer <dtro...@gmail.com> wrote: >> > On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann >> > <doug.hellm...@dreamhost.com> wrote: >> > > Do we need to specify this beyond saying that all subcommands must use >> > > argparse for argument parsing (the new framework depends on it anyway, >> > > and >> > > then they are all consistent)? >> > >> > We should document that, I had just assumed it until now. >> >> Agreed. > > Sorry, that made me think of another newbie question - is the > intention that all actions (including user- / site- / vendor-specific > extensions) *must* be implemented in Python using the client API > modules? Or will it also be able to support extensions simply by > dropping arbitrary openstack-ACTION executables on $PATH? I like the > way git lets you do the latter, e.g. I have a bunch of shell scripts > named git-something in my own ~/bin which help me extend git and > automate my git workflows, and they can still be invoked via `git > something'. In case you're curious, here they are ... >
That made me think of something. Is the intention for the client to be portable? Defining portable as : Easily deployed to a host Minimal dependency set Cross operating system portability ( pipe dream but python is solid at it ) Strikes me that having the package end up being portable would be a huge boon to openstack. -Matt _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp