How to Maintain 60 Integrations and Not Go Bananas

Say you've built a library whose main value is providing built-in integrations with a considerable number (say 60+) of different Python packages. That's cool, and your users are loving the out-of-the-box experience. (Being blissfully unaware of the lengths you had to go to in the background to make things work "seamlessly" helps.) Everything seems to be working fine, you get the odd bug report or feature request, the usual.

Then one day you wake up and your otherwise fairly chill issue tracker is drowning in folks experiencing an issue with your library that breaks their app. Your first thought is, why is this coming up now, when your last release was two weeks ago? And then you realize: It's not your release that broke the library.

All the third party code you're integrating with? It's become your code by extension. You need to react if something changes upstream and breaks your integration in unexpected ways. You can write your integrations so defensively that no one will ever want to read them again, but it's not enough: you can't anticipate every single change each of the 60+ packages will ever make.

Let's assume having your users act as a release monitoring system by notifying you on your issue tracker is not what you want. How do you go about this? You'll want somehow to detect breakage early, so you can go fix things before your users are hit by them. And ideally you'd do it in a way that maintaining it is not a nightmare.

This talk will take you through one such journey, from recognizing the problem, to various attempts at making it better, to eventually arriving at a solution that's good enough for now (tm).

You might like this talk if you:

• Have to deal with integrations in some shape or form
• Are relying on third-party packages heavily
• Don't like maintaining things by hand
• Like to have that "this can be automated with a script" itch scratched
• Are intrigued that there's a talk that has the word "bananas" in the title