-------- Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead, go instead where there is no path and leave a trail." On Thu, Sep 24, 2020 at 7:15 PM Brian Bouterse <bmbou...@redhat.com> wrote: > > > 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. > > I agree that in the long run we don't want having everything in one > package; given our recent experience with all the dependencies we have > during the release process this will add yet another drop to the > complexitiy. > > 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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev