WIP: Taskchampion bindings for python

[illya-laifu]

Taskchampion bindings for python

Installation

The dependency management is done via poetry, to install the dependencies, from the py-lib run:

poetry install

To build and install the package into current environment:

poetry run maturin develop

To run tests:

poetry run pytest

Currently implemented and tested:

• Annotation class and the getters/setters for the two fields.
• Replica class (::dependency_map method needs more testing and polishing due to the Rc reference)
• Status enum
• Tag class
• Task class *
• WorkingSet class

Implemented but not tested:

• DependencyMap class
• Storage concrete classes.

TODO:

• Be able to construct replica by passing in the specific Storage implementations (e.g. InMemoryStorage, SqliteStorage or users own implementation of Storage)
• Current Task class is the immutable version of it, it would be nice to extend it to also include the methods from TaskMut and convert to and the mutable state in those method calls. It is impossible to implement the TaskMut via pyo3 due to the lifetime parameters.*
• Be able to iterate over WorkingSet via next() and with for item in ws:, but this needs it to hold the reference to an iterator.
• Python has it's own uuid library, currently the methods that accept a UUID, do that by accepting str and converting it into the rust's implementation of UUID.
• Better documentation, but the Rust comments on the pyo3 annotated functions/objects directly translate into the docstrings.
• Not entirely sure if it is possible (need to research), but it would be convenient to provide signature stub files along with the library, so the Language Servers, linters and such would be able to infer the types.
• Either split this into a separate repo, since maturin generates multiple github workflows, or rename the py-lib into something sensible.

[djmitche]

I don't know Py03 well enough to really review this in detail, but structurally this looks great!

When this is ready for review, I will try to learn enough to verify

• it does what it says on the tin
• it does not make any promises to users that we cannot keep (e.g., making an assumption that TaskChampion doesn't actually support)
• it seems safe :)

I have a minor concern that refactors of TC (notably #372) will cause breaking changes to bindings like this. However, I think that's OK at this stage -- we can make a major version release of TC, with well-documented required changes, and consumers can upgrade as necessary.

[djmitche]

All three of these are valid criticisms of the Rust API, and problematic for embedding in other languages, too. I'd be happy to see PRs to simplify these Rust APIs. In fact, #372 is one such.