-------- 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 Fri, Sep 25, 2020 at 2:48 PM Matthias Dellweg <mdell...@redhat.com> wrote: > This is all interesting, but as one of the goals of the cli is to not be > dependent on specific versions of pulpcore/plugins, there should be no need > to release a new version _with_ them. > Surely it would be good to release subcommands for new features shortly > after they go GA, but there should be no technical need for co-releasing. > Right, I am with you on this. I was mostly talking about the case when if having all in one repo, then because of only one plugin X needs (new rfe, new command/subcommand) we would need to release. > > (Thinking about that, the CLI might be able, with version guards in place, > to support features even before they are released.) > > On Fri, Sep 25, 2020 at 2:38 PM Ina Panova <ipan...@redhat.com> wrote: > >> >> >> >> -------- >> 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 >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev