On Wed, Sep 23, 2020 at 3:31 PM Robin Chan <rc...@redhat.com> wrote: > > Robin Chan > > She/Her/Hers > > Satellite Software Engineering Manager - Pulp > > Red Hat <https://www.redhat.com> > > IRC: rchan > > Red Hat respects your work life balance. Therefore there is no need to > answer this email out of your office hours. > <https://www.redhat.com> > > > > On Wed, Sep 23, 2020 at 12:45 PM David Davis <davidda...@redhat.com> > wrote: > >> ## Sept 23, 2020 >> >> * [david] Finish CLI PoC demo and upload to asciinema >> * Send out email to pulp-list about PoC? >> * Include asciinema >> * How to install, use CLI >> * Ask for feedback >> * Contact mcorr first and see what she recommends >> * Should we meet regularly? >> * Meet again in two weeks >> * Hopefully have some user feedback >> * We need a decision about where to have the cli code >> * it's not urgent. >> * for now, keep using a single repo >> > I was hoping someone would chime in here on what would be the cli > experience of a plugin that isn't in the pulp org - say debian or chef? > What would be simplest? Or is there an option that would be hard to change > back the other way? This seems like a pretty important decision. I'd like > to see some use cases or requirements that might help determine a decision > or rule out any. And I'd like to hear from other stakeholders. > I agree simplicity is key. Here are some questions/thoughts I have to try to determine what simple looks like
One question I have is: will plugins have custom commands. I suspect the answer is yes because even if the CLI package itself is smart enough to auto-produce all the generic commands from the API spec, I suspect in most cases plugins will want "custom commands". So if that's a yes, how will they ship those? While it's simple to add them to the one CLI repo, it's complicated for users to get the "right" version for them when it's all in one package. In fact that may be impossible. So not as simple, but likely more usable would be for any custom CLI commands to ship as a "CLI plugin package" aka a python package that will give extra commands and have this auto-release when the plugin itself releases. What wouldn't be simple is an additional repo for each plugin that would require additional complexity at each plugin release. The final question I wonder about is testing: How will CI be done on these commands? My take is probably simplistic, but CI it anywhere plugin bits are released from so if that's one main repo for the CLI CI those parts there, and then CI any custom commands from repos where they are released from. This is what I was thinking about, but I am ok with anything the CLI teams would be better or simpler. > >> * Supporting multiple versions of pulpcore and plugins >> * For now, use conditional statements when needed >> * Versioning of the CLI >> * Needs more thought >> >> David >> _______________________________________________ >> 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