Add support for other platforms?

[joshuadavidthomas]

So, with * gestures around this site * everything that's been going on with the GitHub platform, I'm starting to think of moving my personal repositories elsewhere. As I think about that and what it would take, it does make me wonder about this library though.

We lean heavily on gidgethub to do all the plumbing necessary for interacting with GitHub, with this library just some nice sugar on top to make it easy to work with in a Django project. So... I'm starting to think through ideas about how we could refactor to support other platforms.

One idea I had would just be to keep everything in this library still, but transition to the Django-standard "backends" style architecture, with all the different platforms as different backends. That works! But! It would be a lot to take on, and I don't see myself using e.g. something like GitLab anytime soon. But it's hard to imagine moving to a more generic style library with backends and not having GitLab support.

An interesting thought would be to instead design the application with plugins using pluggy -- I've used it in other libraries to great success, and it could be a good fit here. And it would alleviate me from having to add support for a platform I have no real interest in using (at least at the moment!).

Going with the plugin approach could also potentially ease the transition, at least I think so? Refactor everything to use the hookspecs and then have a first-party GitHub plugin in the library that just has hookimpls for GitHub. That way from the outside nothing would change (hopefully!).

I imagine I would have to create a new package, name pending, and create one last release for django-github-app on PyPI that points to the new package -- I don't think you can rename a library on PyPI, but I could be wrong on that. More thoughts needed on that I guess..

[joshuadavidthomas]

OR! Keep this library, create a new one that's the core including the hookspecs, and migrate this to using that approach only. So people would install both or even just include the core library as a dependency of this library..

[joshuadavidthomas]

Though honestly, a plugin based system would almost be just a generic webhook handler library, not just VCS host specific. I have no idea if something like that already exists -- likely, but probably not in the shape we would need..

[joshuadavidthomas]

I guess the whole question is how abstract do I want to get. Go all the way to a generic webhook handler library, or just scope it down to common VCS providers? (I know which one I should choose, but I know which one I want to build. 🤣)