openstack team mailing list archive

[Matt Joyce <matt@xxxxxxxxxxxxxxx>]

On Tue, May 1, 2012 at 11:49 AM, Adam Spiers <aspiers@xxxxxxxx> wrote:
> Doug Hellmann (doug.hellmann@xxxxxxxxxxxxx) wrote:
>> On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer <dtroyer@xxxxxxxxx> wrote:
>> > On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann
>> > <doug.hellmann@xxxxxxxxxxxxx> 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