[Pulp-dev] RFC: pulp command line interface

Matthias Dellweg mdellweg at redhat.com
Tue May 12 07:24:59 UTC 2020

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 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>

More information about the Pulp-dev mailing list