[Pulp-dev] CLI team meeting notes

[Ina Panova]

--------
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 <mdellweg at 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 <ipanova at 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 <bmbouter at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 23, 2020 at 3:31 PM Robin Chan <rchan at 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 <daviddavis at 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 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
>>>>
>>> _______________________________________________
>>> 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/20201001/43f0db05/attachment.htm>