Hi Gaute, On Thu 08 Oct 2020 at 10:13 +0200, Gaute Hope wrote: > I made another attempt at porting lieer to notmuch2, but I am missing the > get_directory method still. Any plans to look at it? Would indeed be good to add this sometime. I'm still curious to how you use it though to make sure we make a good API. I only found https://github.com/gauteh/lieer/blob/394d8c1a574fd57e63390e92a6e73363808ebac5/lieer/local.py#L280 and it seems you only use the `.path` attribute. Is this correct or did I miss anything? Cheers, Floris > > Regards, Gaute > > On Sun, Nov 17, 2019 at 6:14 PM Floris Bruynooghe <flub@devork.be> wrote: > >> 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 >> _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org