RFC: Plugin API

[StephanMeijer]

Also, more generally, it might make sense to implement a plugin api so that people can use custom services without them having to be community maintained. On the other hand I'm not sure our current api is all that great and it might be inconvenient to have to consider backwards compatibility when refactoring.

• @ryneeverett in #770

[ryneeverett]

Another disadvantage to this could be that people are less likely to do all the work contribute new services that are fully complete and include tests if it's easier to add them as a private service without having to maintain a bugwarrior fork. A compelling reason to push one's service into bugwarrior today is to avoid having to keep rebasing your fork. I don't think this is a good reason to reject this feature outright but is a factor in the cost/benefit analysis.

[StephanMeijer]

I think you have a point.

[ryneeverett]

It appears that it is or at least was already implemented in #245. Perhaps it just needs documentation.

[StephanMeijer]

How could this for example be used for someone's own private plugin-directory?

[ryneeverett]

I'm not exactly sure but I believe the answer lies in these documents:

• https://setuptools.readthedocs.io/en/latest/pkg_resources.html
• https://packaging.python.org/guides/creating-and-discovering-plugins/

[ryneeverett]

Still relevant and still happening but closing in favor of tracking in #791.