From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4MgVFB7Kfl/qXAAA0tVLHw (envelope-from ) for ; Thu, 08 Oct 2020 08:13:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id IODbDx7Kfl9gGwAAbx9fmQ (envelope-from ) for ; Thu, 08 Oct 2020 08:13:18 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [IPv6:2607:5300:201:3100::1657]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CADB9940224 for ; Thu, 8 Oct 2020 08:13:16 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id B752F1FFFC; Thu, 8 Oct 2020 04:13:06 -0400 (EDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by mail.notmuchmail.org (Postfix) with ESMTPS id 0FE761FFA8 for ; Thu, 8 Oct 2020 04:13:04 -0400 (EDT) Received: by mail-wr1-x42f.google.com with SMTP id g12so5510474wrp.10 for ; Thu, 08 Oct 2020 01:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaute-vetsj-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=riMJfAxmdEYDQVsZfg2wxYr4T47eK/UFrOTlet0zdic=; b=TMxqSpHpkvMQNse73oudvaphrgihWni9LjxKcV0k94P+pGsvS30r0uBYT6ro85EmCU DDiCN1DskKK/18ARivbJW4U7ecKIGPR6oXgJy2cEz5NwDpMGuHW9UHjv28rbFpDatRmI dCQIKTfEAzcstub39esn5kZNr50JwNU0D0ZEjYfAFFSE418s4E5JexOKfKeqKUEdf5vV XiieG0MtR0CIQlSsGmv+IuA3ghqaHv2Prqpe6K1BgMeHjmyT3r3pz4Gf3brzz9exb5Jg QXMJbd+sAP2Fz7EZZ6kD1E5WfuvpCCPTkbI06g7/Yrrxd5bpbabjcy83Jtg5ZYqoDarw HMnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=riMJfAxmdEYDQVsZfg2wxYr4T47eK/UFrOTlet0zdic=; b=S2b8g4Jh6t2siddRd9fQIwkcVNx2mdtLah+J1HtNUdJRhH9iEQzlkFTLtVdFugs4Sq YBUK5p9pfBU8AsiRNvCneOchSlh7xvAe9c+WKkUDM9aGKamBXTQ73ved2xd8PFLxVhcK C+PkZd0dYyWO4wP1/DESWKwA0CurZFHXtTE9pqdTND1u/yQOuyEcN30HrMUX1vTc/GQm YqAty7PNhN2Pwjziw/UdZZ1PSiIOesp/h7RY9RFGqMANqRlIs46Gvxf60hqub5o971II v4z6CZlLAsBBwz8VyNM6VraizDvmRjct+jZjtkTEUPb1R+8Z+EMowAc2KKWWijk7MH6f o+aA== X-Gm-Message-State: AOAM5310coc7/uvL623omi7KFGos+y26VG+BxQHE4N1bDbFkBRkT8OKK MZNobeJLdWOpsDeOolTWA4tW/4Ku3dKO+mJ9kzFsCA== X-Google-Smtp-Source: ABdhPJyCdP413unpJxx45gg+91BwVAxrgjZchARhNY1f9St92R6nvY/tPs2yM1PJ7FjJBZrZuTOt2nA321IsGIofTX4= X-Received: by 2002:adf:c3c2:: with SMTP id d2mr8145924wrg.191.1602144782312; Thu, 08 Oct 2020 01:13:02 -0700 (PDT) MIME-Version: 1.0 References: <20191008210312.20685-1-flub@devork.be> <87y2wepgq8.fsf@powell.devork.be> In-Reply-To: <87y2wepgq8.fsf@powell.devork.be> From: Gaute Hope Date: Thu, 8 Oct 2020 10:13:37 +0200 Message-ID: Subject: Re: Python3 cffi bindings To: Floris Bruynooghe Message-ID-Hash: YVW4SOX2UTU5IWI3WCA73FCAESTZTO5P X-Message-ID-Hash: YVW4SOX2UTU5IWI3WCA73FCAESTZTO5P X-MailFrom: eg@gaute.vetsj.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: notmuch X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============1991273826908652003==" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=gaute-vetsj-com.20150623.gappssmtp.com header.s=20150623 header.b=TMxqSpHp; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 1.03 X-TUID: jDWAJNNPqaSS --===============1991273826908652003== Content-Type: multipart/alternative; boundary="000000000000a1058d05b124665b" --000000000000a1058d05b124665b Content-Type: text/plain; charset="UTF-8" Hi Floris and others, I made another attempt at porting lieer to notmuch2, but I am missing the get_directory method still. Any plans to look at it? Regards, Gaute On Sun, Nov 17, 2019 at 6:14 PM Floris Bruynooghe 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 > --000000000000a1058d05b124665b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Floris and others,

I made another at= tempt at porting lieer=C2=A0to notmuch2, but I am missing the get_directory= method still. Any plans to look at it?

Regards, G= aute

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.=C2=A0 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.=C2=A0 Maybe notmuch_database_get_path() is the only=
entrypoint here and you can get further by listing files and directories from it?=C2=A0 But maybe people then use the filesystem directly to find a<= br> directory and create the directories ad-hoc.

I grepped lieer but I think you only use it in one place?=C2=A0 And if I understand it correctly you only do this to check if your mailstore/cwd
is inside the notmuch database.=C2=A0 I.e. this is equivalent to checking i= f
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.=C2=A0 I guess if the bindings are in the mai= n
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<= br> > get away with a bug version bump in the bindings rather than creating<= br> > 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 pa= inful
for you I am very weary of knowingly breaking APIs.=C2=A0 I'd rather ha= ve
people have an easy migration rather than unexpected breakage after an
upgrade.


Cheers,
Floris
--000000000000a1058d05b124665b-- --===============1991273826908652003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1991273826908652003==--