[katello-devel] Started going through a setup

[James Slagle]

On Wed, Jul 20, 2011 at 08:13:00AM -0400, Todd Sanders wrote:
> On 07/20/2011 08:11 AM, Lukas Zapletal wrote:
> >On 07/20/2011 02:03 PM, Todd Sanders wrote:
> >>
> >>I still believe we should find a way to leverage this from the
> >>pulp-admin cli core; as all of this has been built.  No reason to keep
> >>spending cycles reinventing this.  In pulp-admin, we allow for -u -p
> >>*before* the command; and --username --password after the command.  We
> >>also allow for you to pull down a certificate to be used with successive
> >>commands via the CLI:
> >>
> >>pulp-admin auth login --username <username>  --password <password>
> >>
> >>We are in the process of refactoring/reorganizing the pulp client code;
> >>I'll have slagle take a look at reuse for the katello cli.
> >
> >I guess the codebase was copy&pasted from pulp. It probably
> >diverged at some point. Would be good idea to track the
> >improvements from pulp git repo and "cherry-pick" them into the
> >Katello.
> >
> >+1 for this approach
> >+1 for certificate auth
> >
> James:
> 
> Would be nice for us to be able to leverage some of the
> infrastructure that is built into the pulp-admin cli within our
> katello cli.  As you are working on some refactoring/reorganization
> in this sprint, can you chat with Lukas about how to make this
> possible.  If we can get away with something better that cut-n-paste
> that would be good...but either way, we should find a way to take
> advantage of what's already been developed.

In pulp, the only command where username/password is allowed after the command
is auth.  This seems to be because the auth command itself requires username
and password arguments.  The other commands don't allow it, it must be
specified before the command.

Arguments are parsed for the the main client program first, and then control
is passed off to the specified command, which then parses it's own options.

I'm not sure if there is a "standard" way of doing it.  I'm more of a fan of
the arguments that apply to the main program having to come before the
command.  I think it typically leads to less confusion since each command
usually has it's own unique set of arguments.  If they can be specified in any
order, in gets much more difficult to parse things correctly.  I'm not sure if
the standard python option parse library (optparse) allows for quite that much
flexibility.

--
-- James Slagle
--