Feature Request: Package as Django "app" for reusability

[danpalmer]

One of the nice features of this project is the ability to create custom interactions to power team processes.

Problem

Unfortunately to do this, users must essentially fork the codebase, add new actions, and then keep their branch up to date with master here. This isn't ideal for several reasons:

• It's not obvious when new features/fixes/security releases are available upstream
• It's not easy to update to only particular published versions (tags?)
• Merging changes, particularly those to do with the infrastructure stuff here (Dockerfiles, etc) may be tricky.

Solution

I propose that a good solution for this would be to make response a Python package that provides a Django app.

What would this look like?

• The existing apps: core, pagerduty, slack, and ui would be moved into the response app.
• The response app would be decoupled from the Django installation currently there – removing manage.py, changing how the settings work, etc.
• A new demo site would be created, that adds response to its INSTALLED_APPS, and perhaps implements one additional command to demonstrate how the extension would work.
• The Docker setup provided would be updated to launch the demo site.
• The response package would be published to PyPY, ideally with a nice CI setup in this repo for testing and publishing new versions.

This has the benefits of:

• Pending updates are now just out of date Python packages, and we can use tooling such as Dependabot/piprot to detect, or the GitHub vulnerability alerts.

• Updating to a new version is as simple as bumping the version requirements in your requirements.in or equivalent file, again utilising existing Python tooling such as pip-tools, pipenv, etc.

• Merging changes is now much easier, and only becomes an issue when the public API of the response package changes (which can be tested for) rather than happening on conflicting file diffs.

• Including custom infrastructure/deployment tooling in the repo is easier as it's not co-existing with the demo tooling provided here.

• • -

I'd appreciate any feedback or discussion on the alternatives to this approach – I'm sure there are other good options here.

[AshleyPoole]

I think this is a really good suggestion and topic to discuss. As someone who has forked this project and actively making customisation's and trying to contribute them back to master where appropriate, reducing some of the friction would be nice.

We ran into the same topic with our previous bot and decided to split the project into three to help with this issue:

• Web project hosting the bot -- references the bot framework package and modules
• Bot framework
• Bot modules

[evnsio]

@danpalmer I like the idea and agree the current forking model is less than idea. Do you have anytime to help work on this idea?

[danpalmer]

@evnsio I may be able to dedicate a day to this (depending on if we're going to use this at Thread or not), unfortunately this is probably about the limit of what I can dedicate.

I'm a little reluctant to do this, as I don't want to sink a day of work into this to have the PR/approach rejected or have another ~day of changes requested, as I would be unlikely to be able to complete this. It would be good to agree on what you're happy with before starting.

[victorliun]

Had this idea too, but now I am thinking it would be more flexible to have an open API for creating incidents. Response will provide an API e.g. POST /slack/action with an incident detail in the payload. Response can also provide a library as a helper to setup connects and send the post, so other applications just need to install this little library with proper configuration to use Response.

[danpalmer]

@evnsio i May have some time to start on these changes this week. Are you happy with the rough plan? I am currently working on AEST so back and forth will unfortunately take a day, so it would be good to get some guidance before I start (potentially Tuesday).

[milesbxf]

@danpalmer I've just started looking into this, and your solution looks great. Have you done any work towards this so far? I'm happy to start consolidating apps into the response app

[danpalmer]

This has essentially been completed now, huge thanks to @milesbxf 🎉

[danpalmer]

Apologies! While @milesbxf has made significant progress towards this, it's not yet complete. I'll leave this open until the release branch merges into master and a release goes to PyPI!

[milesbxf]

@danpalmer we're looking at merging release-0.1 very soon 🎉

We've started pushing a few releases to PyPI here which you're very welcome to start using - consider these versions alpha and prone to breaking changes for the moment. Hopefully we can work towards a slightly more stable model of development

[milesbxf]

We've just merged to master and released v0.1.1 🎉

https://github.com/monzo/response/releases/tag/release-0.1.1