taskchampion integration

[ryneeverett]

In the last community meeting @djmitche mentioned that he was interested in seeing an integration of taskchampion into bugwarrior and I'd be curious for his thoughts on that. There is an effort to create python bindings to taskchampion -- https://github.com/GothenburgBitFactory/taskchampion-py -- and I'm curious if we should be depending on an upstream like that or creating our own bindings for the presumably minimal subset of the API we actually need to use.

My primary concern I hope Dustin can address is about taskchampion's database schema version interoperability. As I understand it, bugwarrior would have taskchampion as a dependency, so breaking changes in taskchampion wouldn't be an issue because we'd be linking against a version of our choosing. However, the user's taskwarrior installation might be linked to a different version of taskchampion and the database might have a different schema. How much interoperability should we expect between different taskchampion versions going forward? I suspect it would be very disruptive to our users if bugwarrior didn't have several years of interoperability with taskwarrior.

[djmitche]

My intention is for sync to be the means by which different applications communicate, rather than sharing a database. Having thought about modifying the sync protocol by adding more operations in GothenburgBitFactory/taskchampion#373, I suspect this is nearly impossible, so I think this is likely a very stable way to interoperate.

Sync can be performed locally, so even for a single-machine setup this should be pretty straightforward.

That said, I'm sure folks will want to use a single DB for both bugwarrior and taskwarrior, so we should at least make that option as good as we can. GothenburgBitFactory/taskchampion#477 should help to at least prevent DB corruption if DB versions don't align -- at the cost of making one of the two applications fail with a DB version error. And, it's worth noting that the operations work was a pretty major change to TaskChampion and I don't expect that to happen too often. Breaking task properties out into a task_property table for easier querying is the only incompatible schema change I can see on the horizon, and I'm not even sure that's a good idea (virtual indices might be a better idea, and are backward compatible).

Regarding the Python bindings -- I'd prefer to depend on an upstream, just to focus attention on the quality of that upstream.

[ryneeverett]

I'm curious if you have any thoughts about the future of the current python binding libraries -- taskw and tasklib. They're both designed to accommodate multiple backends and it seems like it wouldn't be too difficult to add a taskchampion backend. Seems like the only difference is that consumers of the taskchampion backend would have to initiate synchronization since it wouldn't operate on the taskwarrior replica. One advantage is that applications could easily maintain a fallback or alternative of the command line interface in perpetuity...if that is an advantage. It would also make upgrading taskwarrior-2 dependencies of these packages trivial, but I don't know how many are worth saving.

[djmitche]

I'm not sure my opinion should carry much weight, as I'm not too familiar with either one, but here goes..

It looks like taskw is a little lower-level and might benefit from communicating directly with TC. That it has a TaskwarriorDirect backend reinforces that notion. If the backend were configured mostly with the sync information, and treated the local repo only as a local cache, then sync'ing before and (when modifications were made) after would feel pretty natural.

On the other hand, tasklib seems a little higher-level and might lose something in trying to re-implement its query language against TC, without TW's interpretation of values, date/time expressions, and so on.