Re: Python3 cffi bindings

[Floris Bruynooghe <flub@devork.be>]

Hi Gaute,

Thanks for trying this out!

On Mon 04 Nov 2019 at 11:27 +0100, Gaute Hope wrote:
> I just checked out the wip/cffi branch on git.notmuch.org with the
> purpose of porting Lieer (https://github.com/gauteh/lieer). There
> seems to be some missing functionality: `Database.get_directory()`
> specifically.

Yeah, I didn't add that yet because I don't fully understand how it
should be used.  Specifically I don't know where one might get a
pathname from to pass to .get_directory() and thus whether the API would
be cleaner to just return a reasonable directory object from whatever
location that might be.  Maybe notmuch_database_get_path() is the only
entrypoint here and you can get further by listing files and directories
from it?  But maybe people then use the filesystem directly to find a
directory and create the directories ad-hoc.

I grepped lieer but I think you only use it in one place?  And if I
understand it correctly you only do this to check if your mailstore/cwd
is inside the notmuch database.  I.e. this is equivalent to checking if
your mailstore/cwd has notmuch2.Database.path as prefix which you could
easily do directly rather than using the FileError exception from
.get_directory().

So is anyone else aware of some code which uses db.get_directory() to
give an idea of how and why this is used?

> I also ran into a couple of warning when building
> (included below).

Thanks for pointing these out.  I guess if the bindings are in the main
repo only the latest library version can be supported without any
further concerns.

> By the way, it does not seem that the API is very far from the
> previous python API. If it is close enough, perhaps it is possible to
> get away with a bug version bump in the bindings rather than creating
> a new package. I understand the need for a new package, but it would
> be nice if we could avoid the future confusion of two python binding
> packages (if at all possible).

While I'm glad to hear that you think a migration wouldn't be to painful
for you I am very weary of knowingly breaking APIs.  I'd rather have
people have an easy migration rather than unexpected breakage after an
upgrade.


Cheers,
Floris