[Pulp-list] Puppet in the CLI

[Michael Hrivnak]

I like this newest version as well. While there may not be much of a practical difference between "pulp-rpm repo list" and "pulp-admin rpm repo list", keeping one unified executable seems to give psychological encouragement to keep extension CLIs consistent.

What first came to mind is the "ip" command, which has similar challenges in terms of operating on different types of objects such as routes, links, tunnels, etc. Its approach is similar to your newest proposal. Here is its signature:

ip [ OPTIONS ] OBJECT { COMMAND | help }

For example, "ip route list" where "route" is an object type, and "list" is a command.

It's worth noting that the "ip" command came about largely to unify the functionality and interface of several disparate networking commands. For pulp to have similar unification up-front will prevent interface divergence over time as the scope and number of extensions increases.

Michael


----- Original Message -----
From: "Jay Dobies" <jason.dobies at redhat.com>
Cc: pulp-list at redhat.com
Sent: Wednesday, August 22, 2012 8:41:06 AM
Subject: Re: [Pulp-list] Puppet in the CLI

On 08/22/2012 02:43 AM, Jason Connor wrote:
> I'm also leaning toward option 2, version 2.
>
> I tried mental exercise on a 3rd version. Namely and auto-type detecting script, but you hung up on the help flag alone, so I don't think it'll fly.
>
> O2V2 is, imo, the cleanest.

I thought of a O2V2 this morning where we keep a single pulp-admin 
script but branch at the root of the commands:

pulp-admin rpm repo ...
pulp-admin puppet repo ...
pulp-admin generic repo ...

It's basically the same concept of individual trees of commands, but a 
single script. I'm still leaning towards O2V2, but figured I'd throw 
that out there.

> Jason L Connor
> linear on freenode #pulp
> http://pulpproject.org/
> RHCE: 805010912355231
> GPG Fingerprint: 2048R/CC4ED7C1
>
>
>
> On Aug 21, 2012, at 9:40 AM, Jay Dobies <jason.dobies at redhat.com> wrote:
>
>> https://fedorahosted.org/pulp/wiki/GCCLITypes
>>
>> When first adding the RPM extensions, I knew we'd have to figure something out when we supported Puppet but decided to hold off on the decision and see how things took shape.
>>
>> It's time to revisit the CLI structure and how to handle the fact that the Pulp team is now providing support for 2 different plugin packs, keeping in mind that that number may grow depending on what other types of content we decide to bite off and maintain as a team (or get contributed).
>>
>> The page above describes my thought process in how to handle our admin CLI with multiple types. I included some chat conversations with the community on what they think as well.
>>
>> It's pretty clear reading it which way I'm leaning. I'd like to come to a conclusion following the scrum meeting tomorrow, but I don't want to wait that long to hear any brilliant ideas you have on the issue since I'll probably start down a path this afternoon. So please reply to this or me personally if you have a strong opinion in any direction.
>>
>> --
>> Jay Dobies
>> Freenode: jdob @ #pulp
>> http://pulpproject.org | http://blog.pulpproject.org
>>
>> _______________________________________________
>> Pulp-list mailing list
>> Pulp-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-list
>


-- 
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org

_______________________________________________
Pulp-list mailing list
Pulp-list at redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list