see inline On Mon, May 11, 2020 at 10:14 PM Brian Bouterse <bmbou...@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 <davidda...@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 <mdell...@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@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev