[Pulp-dev] Ideas for the plugin template

Brian Bouterse bbouters at redhat.com
Mon Jun 18 16:16:28 UTC 2018


+1

On Mon, Jun 18, 2018 at 8:47 AM, Ina Panova <ipanova at redhat.com> wrote:

> +1
>
>
>
> --------
> Regards,
>
> Ina Panova
> 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, Jun 14, 2018 at 10:19 PM, Bihan Zhang <bizhang at redhat.com> wrote:
>
>> +1
>> I think the plugin_template is very valuable for bootstrapping plugin
>> development, but we have had issues with keeping it up to date. Creating a
>> smash test that will enforce this on new PRs make perfect sense to me.
>>
>>
>>
>> On Thu, Jun 14, 2018 at 11:29 AM, Austin Macdonald <austin at redhat.com>
>> wrote:
>>
>>> I've recently updated the plugin_template to work with the latest
>>> master (3.0). [0] The template handles almost all of the bootstrapping
>>> work necessary to write a new plugin, so it is valuable to keep it up to
>>> date. Given human nature, it's likely that the plugin_template will tend
>>> to fall behind as it did recently. I have some ideas to save time while
>>> keeping the template current and useful.
>>>
>>> 1) Move the plugin writer docs [1] into the plugin_template repository
>>>         - Leave a (very) high level overview in the core docs with a
>>> link to
>>>           the template docs.
>>>         - Plugin writer docs PRs would only go to one place, and it would
>>>           be easier keep the docs in line with the code.
>>>         - Narrative docs in the template would explain what needs to be
>>>           done generally, linking to the modules.
>>>         - Specific instructions would live in the code modules alongside
>>>           basic working code, and additional commented out code
>>>           to demonstrate and explain more complex behaviors.
>>>
>>>  2) Add pulp_smash tests for basic functionality of a bootstrapped
>>> plugin.
>>>          - Run these tests as a check on pulpcore and template PRs
>>>          - Ensure that discoverability works
>>>          - Fail with breaking Plugin API changes
>>>          - If the test uses pulp_smash, it would include a base set of
>>>            integration tests for every new plugin.
>>>
>>> My reasoning is that no matter what changes we make to pulpcore,
>>> we need to keep the plugin writer docs updated. Doing this in the
>>> template will provide value for plugin writers, and will inform pulpcore
>>> developers when it needs to be updated.
>>>
>>> [0]: https://github.com/pulp/plugin_template/pull/9
>>> [1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin-writer
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20180618/a9d5e7e6/attachment.htm>


More information about the Pulp-dev mailing list