pyThings is a Python library used to create and call x-callback-urls with the assistance of xcall.

Here is an example of creating some Projects (Epics) and Tasks (Stories) via another bit of logic (dry details of the items withheld):

Things auto populating projects and tasks

This was created in haste to include in some other unnecessary automation of daily tasks and time tracking. This library supports most of the URL Schema published by Cultured Code on their documentation page here.

Add/Update a Task:

>>> from pyThings.tasks import AddTask
>>> AddTask(title='A New Task')
>>> from pyThings.tasks import UpdateTask
>>> UpdateTask(auth_token=auth_token, task_id='ID_STRING', completed=True)

Add/Update a Project:

>>> from pyThings.projects import AddProject
>>> AddProject(title='My New Project')
>>> from pyThings.projects import UpdateProject
>>> UpdateProject(auth_token=auth_token, task_id='ID_STRING', completed=True)

As I mentioned in the README, while Things Callback URL Scheme is robust, it is very write oriented. It is not currently possible to get anything from Things as far as I could find, aside from an associated x-things-id upon creation, which is needed to update any Task or Project.

A few things I am thinking about for future release are moving to something like robwalton/python-xcall which is a client for bi-directional communication with x-callback-url. As well as removing the execution of the callback url upon class creation, this was dne just to simplify the library in my context, though I realize that may not be a wide use case. The idea of creating Projects and Issues as classes is retaining the information in a diffable format, that can then be cached locally, outside of Things, to be used again (when using this library in syncing from say a project management suite via another tool).

I went as far as digging through the sqlite db Things keeps on disk, but…