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" <[email protected]>
Cc: [email protected]
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 <[email protected]> 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
>> [email protected]
>> https://www.redhat.com/mailman/listinfo/pulp-list
>
--
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
