[Pulp-dev] RFC: pulp command line interface

[Matthias Dellweg]

see inline

On Mon, May 11, 2020 at 10:14 PM Brian Bouterse <bmbouter at redhat.com> wrote:

> Thank you for sharing this! Can a basic README be added showing a few
> things a user could try after installing it from source? I also put a few
> comments inline also.
>
> On Mon, May 11, 2020 at 1:53 PM David Davis <daviddavis at redhat.com> wrote:
>
>> Adding pulp-list to hopefully get user feedback on this.
>>
>> David
>>
>>
>> On Mon, May 11, 2020 at 6:54 AM Matthias Dellweg <mdellweg at redhat.com>
>> wrote:
>>
>>> A first draft of the architecture that should eventually govern the pulp
>>> cli has been completed [0].
>>> The feature set is naturally very limited, since we want to autotemplate
>>> most of this after getting good feedback about the architecture.
>>>
>>> Questions we want to settle at this point are:
>>>   - Is the command structure comprehensive and useable?
>>>     'pulp <plugin_name> <resource_class> [--type resource_type] <action>
>>> <...>'
>>>     'pulp file repository list' === 'pulp file repository --type File
>>> list'
>>>
>> Does ^ mean the user would run `pulp file repository list`? If so then +1
>
Yes, as "file" would be the default type in the file plugin.
I should have included more examples:
  'pulp status'
  'pulp file repository delete --name test_repository'
  'pulp deb publication --type verbatim create --version
/pulp/api/v3/repositories/deb/deb/1234567890/versions/3'
  'pulp rpm content --type advisory list'

>
>   - Is the implemented plugin autoloading useful?
>>>
>> It is useful, but why use importlib with naming conventions rather than
> each cli package declare a python entrypoint? I think entrypoints are a
> more common mechanism of discovery in Python.
>
That was the one i found in the python docs (no extra external
dependencies). I will have a go with the entrypoints.

>
>   - Should we put the cli (plugin-)packages in the corresponding pulp
>>> plugin repos as subpackages?
>>>
>> I'm not entirely sure which is better. I *think* the decision should
> mainly come from how we want to test the CLI packages in CI. If we want to
> test them with every plugin change then we probably do want them in the
> same repo. This is similar reasoning to why we keep the bindings "with the
> plugin". What do you think?
>
I am very glad You asked that question. Iirc, we decided to provide
versions of those cli plugins compatible to the specific versions of the
corresponding pulp plugins. Also they will have a similar strong dependence
on the bindings. So i would even say we want to keep the versions in sync.
Another reason to keep them in the same repository.

>
>
>>> [0] https://github.com/mdellweg/pulp-cli
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200512/98b29924/attachment.htm>