Re: [PATCH v2 2/2] python-cffi: use config_pairs API in ConfigIterator

lgtm i think :) On Wed 16 Feb 2022 at 22:08 -0400, David Bremner wrote: > This returns all of the config keys with non-empty values, not just > those that happen to be stored in the database. > --- > bindings/python-cffi/notmuch2/_build.py | 16 - >

Re: [PATCH 2/2] python-cffi: use config_pairs API in ConfigIterator

On Fri 11 Feb 2022 at 09:04 -0400, David Bremner wrote: > This returns all of the config keys with non-empty values, not just > those that happen to be stored in the database. > --- > bindings/python-cffi/notmuch2/_build.py | 16 +- > bindings/python-cffi/notmuch2/_config.py | 37

Re: Python binding SIGABRT/SIGSEGV

On Thu 10 Feb 2022 at 13:16 +0100, Michael J Gruber wrote: > Austin Lund venit, vidit, dixit 2022-02-10 06:56:12: >> I'm clearly doing this python code wrong by not using the iterator correctly: >> >> > import notmuch2 >> > >> > d = notmuch2.Database() >> > m = list(d.messages("since:today"))

Re: [PATCH 2/2] python-cffi: returned OwnedMessage objects from Message.replies

On Sun 09 Jan 2022 at 09:26 -0400, David Bremner wrote: > One thing I would like to think > about is the length of time it takes to run the pytests. It is not > currently the bottleneck in running the parallel tests for me, but it is > among the slower T*.sh. So it might be nice at some point to

Re: [PATCH 2/2] python-cffi: returned OwnedMessage objects from Message.replies

On Sat 08 Jan 2022 at 10:03 -0400, David Bremner wrote: > If we return regular Message objects, python will try to destroy them, > and the underlying notmuch object, causing e.g. the crash [1]. > > [1]: id:87sfu6utxg@tethera.net > --- > bindings/python-cffi/notmuch2/_message.py | 4 ++-- >

Re: [PATCH] bindings/python-cffi: search for config by default

On Sat 08 Jan 2022 at 12:19 -0400, David Bremner wrote: > The previous (pre-0.34.2) constructor searched for a config file but > only if the database path was not specified, and only to retrieve > database.path. Neither of the available options (CONFIG.SEARCH or > CONFIG.NONE) matches this

Re: Python notmuch2 bridge, something changed in the Database constructor

On Fri 24 Dec 2021 at 09:03 -0400, David Bremner wrote: > > @Floris: when I made the change to the Database constructor, I chose the > default as CONFIG.NONE because this matched the previous semantics > _except_ for finding the database path. But since I don't want to use > the ad hoc

Re: [PATCH] bindings/python-cffi: add matched property to message objects

On Sat 01 Jan 2022 at 10:42 -0400, David Bremner wrote: > Existing users of the legacy python bindings use > message.get_flags(Message.FLAG.MATCH) to determine which messages in a > thread matched. Since the bindings don't provide get_flags anymore, > they should provide a property analogous to

[PATCH] Fix error message when using notmuch_status_to_string

The python exception class was incorrectly loading the error message which resulted in unprintable exception objects. --- bindings/python-cffi/notmuch2/_errors.py | 3 ++- bindings/python-cffi/tests/test_errors.py | 8 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100644

Fix python exception object string repr

This fixes a bug in the exception class which would produce unprintable exceptions because it was not converting an error code correctly to a string. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to

Re: [PATCH 4/4] python-cffi: switch to notmuch_database_{open,create}_with_config

On Tue 02 Nov 2021 at 21:32 -0300, David Bremner wrote: > PS: I took the liberty of replying to the list, hope that's OK. whoops, totally. I keep forgetting to hit the right reply key. Personal feature request: notmuch-reply-dwim, bound to r, which replies to the list for mailing list posts.

Re: [Tomi Ollila] [RFC PATCH] python-cffi out-of-tree build

Hi David, everyone, I had a vague recollection of reading from a single version file before and indeed, looking through annotations it seems commit 3a42abb456893b71b530f099a1467400f2b0ea71 changed this. Seems the concern was that "pip install ." didn't work. So perhaps that's something else to

Re: [PATCH 1/1] python/notmuch2: provide binding for database_get_directory()

s on your > answers below: > > Le 27/07/2021 à 23:01, Floris Bruynooghe a écrit : >>>>> +:raises UpgradeRequiredError: The database must be upgraded >>>>> + first. >>>>> +""" >>>>> +if n

Re: [PATCH 1/1] python/notmuch2: provide binding for database_get_directory()

Hi Ludovic, Thanks for having a look at this! On Sun 25 Jul 2021 at 10:16 +0200, Ludovic LANGE wrote: > diff --git a/bindings/python-cffi/notmuch2/_database.py > b/bindings/python-cffi/notmuch2/_database.py > index 868f4408..e48fa895 100644 > --- a/bindings/python-cffi/notmuch2/_database.py >

Re: [PATCH 0/3] python/notmuch2: a few docstrings and collect_tags()

On Thu 07 Jan 2021 at 17:09 +, Michael J. Gruber wrote: > As for the series: the notmuch based MUA "alot" switched to the new > python bindings recently. collect_tags() is something I used in a > feature PR submitted but not merged yet there (while on the old bindings), > and in my updated

Re: [PATCH 3/3] python/notmuch2: provide binding for collect_tags()

Hi Micahel, Thanks for adding this feature! On Wed 06 Jan 2021 at 10:08 +0100, Michael J. Gruber wrote: > diff --git a/bindings/python-cffi/notmuch2/_query.py > b/bindings/python-cffi/notmuch2/_query.py > index 1db6ec96..a1310944 100644 > --- a/bindings/python-cffi/notmuch2/_query.py > +++

Re: python notmuch2 bindings exclude_tags not added correctly to query

Hi Johannes, On Wed 23 Dec 2020 at 02:34 +0100, Johannes Larsen wrote: > A typo in Database._create_query loses the exclude_tag names during the > string to utf-8 conversion. > > > The problem is fixed by this patch applied to current master (ced341e8): > > diff --git

Re: Adding config cache to notmuch_database_t breaks python-cffi test

On Sun 20 Dec 2020 at 19:22 -0400, David Bremner wrote: Hi David, I'm just catching up on some mailing lists... > David Bremner writes: > >> David Bremner writes: >> >>> I hope Floris (or someone) can tell me what is going on here, I don't >>> understand the memory management in the CFFI

Re: New Python bindings (notmuch2 module) fail to exclude tags

Hi All, On Sat 21 Nov 2020 at 18:51 -0300, Jorge P. de Morais Neto wrote: > Hi Floris. > > Em [2020-11-20 sex 19:17:56+0100], Floris Bruynooghe escreveu: > >> Looking at the implementation I don't seem much that could have gone >> wrong. However I did notice th

Re: notmuch2 (python cffi bindings) segfault gdb logs

Hi Patrick, On Mon 23 Nov 2020 at 10:36 +, Patrick Totzke wrote: > I've been complaining about the new (and old) python bindings causing the > python interpreter to segfault occasionally. So far I was not able to > reproduce this reliably nor provide error traces. This has just changed: >

[PATCH] python-cffi: Extract cdefs from notmuch.h

Instead of having all the required cdefs copied in _build.py this uses the C pre-compiler to extract them from notmuch.h itself. To do this we need to indroduce a few more #ifdefs in the header file since the CFFI parser can not deal with everything the real C parser can deal with, plus it does

python-cffi: experiment with extracting cdefs from notmuch.h

Hi, This is mostly an experiment because I got tired of copying the C function defs from notmuch.h (in other words this was yak shaving while I intended to see if I could get notmuch_database_get_directory supported). I'm not convinced this is better that what we had before to be honest, but am

Re: New Python bindings (notmuch2 module) fail to exclude tags

Hi Jorge, On Fri 20 Nov 2020 at 12:54 -0300, Jorge P. de Morais Neto wrote: > Hi. I am trying to migrate my Python3 script to the new Python bindings > (notmuch2 module). However, I cannot obtain a count of messages > matching a query excluding messages that have an exclude tag. From the >

Re: Python3 cffi bindings

ure 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

Re: [PATCH 1/2] doc: replace use of environment variables with a generated config

On Sat 11 Jul 2020 at 17:00 +0300, Tomi Ollila wrote: > On Sat, Jul 11 2020, David Bremner wrote: > >> I don't love the use of exec, but it is getting unwieldy to pass >> configuration options on the sphinx-build command line, and I >> anticipate further use of conditionals. > > Perhaps less

Re: [PATCH] doc: set up for autoapi / readthedocs compatibility

On Sun 12 Jul 2020 at 09:02 -0300, David Bremner wrote: > sphinx-autoapi seems nicer conceptually (it parses the docs rather > than importing them), TIL about sphinx-autoapi, agree it's nicer conceptually. > but it also generates a ton of warnings, so > leave the default as autodoc. > --- > >

Re: [PATCH 2/2] doc: add new python bindings to main documentatation tree.

Oh, this is very nice! I've been thinking for a while I should attempt this. Great to see it being done! On Sat 11 Jul 2020 at 10:20 -0300, David Bremner wrote: > A seperate conf.py and doc directory will be needed if someone wants > to build the bindings docs separately from notmuch. > --- >

Re: [PATCH 1/2] doc: replace use of environment variables with a generated config

On Sat 11 Jul 2020 at 10:20 -0300, David Bremner wrote: > I don't love the use of exec, but it is getting unwieldy to pass It's already a config file written in Python which is a terrible sin. So no need to apologise, I think it makes sense in this context. > configuration options on the

Re: [RFC PATCH] lib: document new database_open API

On Sat 04 Jul 2020 at 14:01 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >>> + * >>> + * - in the environment variable NOTMUCH_DATABASE, if non-empty >>> + * >>> + * - by $XDG_DATA_HOME/notmuch/$NOTMUCH_PROFILE where XDG_DATA_HOME

Re: [PATCH 2/4] lib: catch error from closed db in n_m_get_message_id

On Sun 05 Jul 2020 at 08:17 -0300, David Bremner wrote: > David Bremner writes: > >> Floris Bruynooghe writes: >> >>> notmuch_database_get_version currently returns and unsigned int and >>> segfaults on use with a closed db. >> >> Yes,

Re: [PATCH 2/4] lib: catch error from closed db in n_m_get_message_id

On Sat 04 Jul 2020 at 14:17 -0300, David Bremner wrote: > Floris Bruynooghe writes: > > >>> - * This function will not return NULL since Notmuch ensures that every >>> - * message has a unique message ID, (Notmuch will generate an ID for a >>> - * message i

Re: [RFC PATCH] lib: document new database_open API

On Fri 03 Jul 2020 at 10:43 -0300, David Bremner wrote: > Several aspects of this are potentially controversial: > > 1) The use of environment variables as fallback. I understand the > discomfort with having a library function check the environment, but > this seems to be functionality people

Re: [PATCH 2/4] lib: catch error from closed db in n_m_get_message_id

Nice. On Mon 29 Jun 2020 at 22:14 -0300, David Bremner wrote: > diff --git a/lib/notmuch.h b/lib/notmuch.h > index ceb5a018..0dc89547 100644 > --- a/lib/notmuch.h > +++ b/lib/notmuch.h > @@ -1363,9 +1363,8 @@ notmuch_message_get_database (const notmuch_message_t > *message); > * message is

Re: Usage after database close

On Sun 28 Jun 2020 at 19:11 -0300, David Bremner wrote: > You need to add a seperate repo for the new style debug symbols in > Debian: > $ (git)-[master]-% apt policy libxapian30-dbgsym > libxapian30-dbgsym: > Installed: 1.4.15-1 > Candidate: 1.4.15-1 > Version table: > *** 1.4.15-1 500 >

Re: [PATCH 2/2] bindings/python-cffi: update version from global version.

On Thu 25 Jun 2020 at 10:34 -0300, David Bremner wrote: > David Bremner writes: > >> Copy machinery from the older python bindings > >> >> +# get the notmuch version number without importing the notmuch module >> +version_file = os.path.join(os.path.dirname(__file__), >> +

Re: Usage after database close

On Sun 28 Jun 2020 at 13:19 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> Hi, >> >> I started writing some test cases to define better what you can do with >> a closed database and make sure that the python bindings do not behave >> unexpecte

Usage after database close

Hi, I started writing some test cases to define better what you can do with a closed database and make sure that the python bindings do not behave unexpectedly here too. One of the first things I tried ends up with xapian calling exit_group(2) directly, terminating the process. So I'm wondering

Re: [PATCH] python-cffi: read version from notmuch version file

On Tue 23 Jun 2020 at 13:43 +0300, Frank LENORMAND wrote: > On Tue Jun 23 12:33:36 2020, David Bremner wrote: >> Frank LENORMAND writes: >> > For example, 0.30.1, with the first two numbers coming from the main >> > repository, and the last one acting as major for the bindings. >> > >> > 0.29.3

Re: [PATCH] python-cffi: read version from notmuch version file

On Fri 19 Jun 2020 at 15:26 +0300, Frank LENORMAND wrote: > On Fri Jun 19 12:46:28 2020, Floris Bruynooghe wrote: >> This keeps it in sync with the main notmuch version which is less >> confusing to users. >> --- >> bindings/python-cffi/setup.py | 10 +- >&

Re: python/notmuch2 on PyPI

On Fri 19 Jun 2020 at 09:30 -0300, David Bremner wrote: > Patrick Totzke writes: >> Just to clarify: alot does not, and will not, depend on packages being on >> PyPI Ah, my bad. I got some github threads mixed up and assumed this had to do with alot. > Notmuch as a project does not currently

python/notmuch2 on PyPI

Hi Thore, notmuch folks, I noticed that Thore published notmuch2 on PyPI. I think this is because alot needs it's users to be able to pull it in as a dependency using the normal Python mechanisms? It seems this is currently published from a fork at

[PATCH] python-cffi: read version from notmuch version file

().strip() + + setuptools.setup( name='notmuch2', -version='0.1', +version=VERSION, description='Pythonic bindings for the notmuch mail database using CFFI', author='Floris Bruynooghe', author_email='f...@devork.be', -- 2.27.0

python-cffi: read version number from notmuch

This reads the version from the toplevel notmuch version file. The main assumption is obviously that setup.py is always in bindings/python-cffi/setup.py together with the rest of the notmuch git repo. ___ notmuch mailing list notmuch@notmuchmail.org

Re: [python-cffi] Version number for the `notmuch2` bindings

On Thu 18 Jun 2020 at 16:56 -0300, David Bremner wrote: > Frank LENORMAND writes: > >> Hi, >> >> The original Python bindings follow the entire repository's version >> number[1]. The new Python bindings use `0.1`[2]. >> >> The Debian package[3] follows the same version number as well, but >>

[PATCH 2/2] python config access: fix style and KeyError bug

This fixes some minor style/pep8 things and adds tests for the new config support. Also fixes a bug where KeyError was never raised on a missing key. --- bindings/python-cffi/notmuch2/_config.py | 9 ++-- bindings/python-cffi/tests/test_config.py | 56 +++ 2 files changed,

[PATCH 1/2] python/notmuch2: add bindings for the database config strings

From: Anton Khirnov --- bindings/python-cffi/notmuch2/_build.py| 17 + bindings/python-cffi/notmuch2/_config.py | 84 ++ bindings/python-cffi/notmuch2/_database.py | 23 ++ 3 files changed, 124 insertions(+) create mode 100644

python: config API

This is a followup on the patch from Anton Khirnov adding config API support to the python bindings. I can not help myself but point out that I did not spot the bug until not only I had written tests, but until I looked at the test coverage to see what was not yet executed and added more tests.

[PATCH 1/2] python/notmuch2: do not destroy messages owned by a query

From: Anton Khirnov Any messages retrieved from a query - either directly via search_messages() or indirectly via thread objects - are owned by that query. Retrieving the same message (i.e. corresponding to the same message ID / database object) several times will always yield the same C object.

[PATCH 2/2] Make messages returned by Thread objects owned

This reverses the logic of StandaloneMessage to instead create a OwnedMessage. Only the Thread class allows retrieving messages more then once so it can explicitly create such messages. The added test fails with SIGABRT without the fix for the message re-use in threads being present. ---

python: Continuing message re-use fix

Hi, This builds on the patch by Anton Khirnov to fix the message re-use that is possible when accessing messages from a thread. I started with just addressing my own comments on this patch, but evolved it into switching the logic around and leave the normal Message object untouched. Instead I

Re: [PATCH] Update tox.ini for python3.8 and fix pypy3.6

On Mon 15 Jun 2020 at 07:06 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> [testenv] >> deps = >> @@ -14,3 +14,6 @@ commands = pytest --cov={envsitepackagesdir}/notmuch2 >> {posargs} >> >> [testenv:pypy35] >> basepython =

Re: [PATCH] Support aborting the atomic context

On Mon 15 Jun 2020 at 07:35 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> This is an implementation of what was suggested in >> id:87v9k96xtl@powell.devork.be It closes the database as that is >> the only safe way to do this afaik. >> >> C

Re: difficulties with notmuch2 python bindings for alot

On Sun 14 Jun 2020 at 19:44 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> One thing that they encountered and don't yet understand is that they >> reported issues with leaking filedescriptors. They used the bindings in >> a way where

Re: difficulties with notmuch2 python bindings for alot

Hi Daniel, On Tue 09 Jun 2020 at 09:19 -0400, Daniel Kahn Gillmor wrote: > I see over on github that alot is trying to port to the notmuch2 > bindings, and having a few problems with it: > > https://github.com/pazz/alot/pull/1511 > > alot is an important consumer of the notmuch python bindings,

python: Update tox.ini for python 3.8

This was released a while ago, we should support it. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Update tox.ini for python3.8 and fix pypy3.6

Python 3.8 has been released for a while now, make sure we keep supporting it correctly. PyPy 3.6 wasn not configured correctly. --- bindings/python-cffi/tox.ini | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/bindings/python-cffi/tox.ini b/bindings/python-cffi/tox.ini

[PATCH] Add missing set methods to tagsets

Even though we use collections.abc.Set which implements all these methods under their operator names, the actual named variations of these methods are shockingly missing. So let's add them manually. --- bindings/python-cffi/notmuch2/_tags.py | 21 +

python-cffi: add missing tagset methods

This issue was found by alot's porting efforts. It seems these were simply missing. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Support aborting the atomic context

Since it is possible to use an atomic context to abort a number of changes support this usage. Because the only way to actually abort the transaction is to close the database this must also do so. --- bindings/python-cffi/notmuch2/_database.py | 16 +++-

[PATCH] Support aborting the atomic context

This is an implementation of what was suggested in id:87v9k96xtl@powell.devork.be It closes the database as that is the only safe way to do this afaik. Currently when the database is closed there are still a bunch of operations which can result in segfaults. Yet the API also promises that

Re: Python 3.x bindings support which versions, exactly?

On Tue 26 May 2020 at 00:41 +0300, Tomi Ollila wrote: > On Mon, May 25 2020, Floris Bruynooghe wrote: > >> In tox.ini the earliest version is 3.5 and if memory serves me right >> there's a reasonably good reason for that. I think the notmuch2 >> bindings use some feature

Re: status of the new python bindings

Hi Anton, Great that you're looking at this API! My apologies for the late response, this slipped by me probably as I was bulk marking things as read when I came back from a few weeks away. On Thu 07 May 2020 at 15:57 +0200, Anton Khirnov wrote: > 1) What is the logic behind choosing whether

Re: Python 3.x bindings support which versions, exactly?

On Sun 24 May 2020 at 16:29 -0300, David Bremner wrote: > Ralph Seichter writes: > >> Hello, >> >> having examined the source code, I assume that Notmuch's Python bindings >> should support Python 3.x for any given 'x'. However, reading the Travis >> logs at https://travis-ci.org/notmuch/notmuch

Re: python-cffi and ruby test suites fail in out-of-tree builds

Hi, On Thu 21 May 2020 at 21:29 -0400, Daniel Kahn Gillmor wrote: > Hey folks-- > > I just did a bit of testing and cleanup for out-of-tree builds (see the > minor patches that should have landed on the list in the last hour or > two). It probably is indeed the unfortunate case that copying the

Re: [PATCH 2/2] python/notmuch2: add bindings for the database config strings

Thanks for adding more of the API! This mostly is fine as well, again I'd mainly ask to add tests however. At least the things which are implemented directly I guess: setitem, getitem, iter and len. On Sat 09 May 2020 at 07:05 +0200, Anton Khirnov wrote: > --- >

Re: [PATCH 1/2] python/notmuch2: do not destroy messages owned by a query

Hi Anton, Thanks for improving the bindings! Any my apologies for the late response, I failed to spot this mail the first time round. Also, this is a pretty serious bug, thanks for finding it. This looks pretty solid, a few small style comments that aren't very important notwithstanding.

Re: [PATCH 1/2] Show which notmuch command and version is being used

On Mon 18 Nov 2019 at 07:43 -0400, David Bremner wrote: > Floris Bruynooghe writes: > >> This add the notmuch version and absolute path of the binary used >> in the pytest header. This is nice when running the tests >> interactively as you get confirmation you're

[PATCH] Move from _add_message to _index_file API

This moves away from the deprecated notmuch_database_add_message API and instead uses the notmuch_database_index_file API. This means instroducing a class to manage the index options and bumping the library version requirement to 5.1. --- bindings/python-cffi/notdb/_build.py| 26 +-

Adressing deprecation warnings

This addresses the deprecation warning pointed out in another thread on this list. It's also a nice self-contained example of adding an API including a new object. This patch is against the wip/cffi branch, it does not rely on my other patch against this branch which renames things. Conflicts

Re: Python3 cffi bindings

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()`

Rename and small tweaks to wip/cffi

Hi, This is a patch against the wip/cffi branch. It does the rename which was discussed before and it adds a small improvment (to me) to the test runner to show which notmuch version is being tested. Let me know if this the right or wrong way to contribute to this branch. Cheers, Floris

[PATCH 2/2] Rename package to notmuch2

i/setup.py +++ b/bindings/python-cffi/setup.py @@ -2,7 +2,7 @@ import setuptools setuptools.setup( -name='notdb', +name='notmuch2', version='0.1', description='Pythonic bindings for the notmuch mail database using CFFI', author='Floris Bruynooghe', @@ -10,7 +10,7 @@ setup

[PATCH 1/2] Show which notmuch command and version is being used

This add the notmuch version and absolute path of the binary used in the pytest header. This is nice when running the tests interactively as you get confirmation you're testing the version you thought you were testing. --- bindings/python-cffi/tests/conftest.py | 7 +++ 1 file changed, 7

Re: python CFFI bindings integration into notmuch build/test

On Sat 16 Nov 2019 at 10:51 -0500, David Bremner wrote: > Floris Bruynooghe writes: >> Anyway, this looks good. Would you like some changes, e.g. the rename >> to notmuch2 or so as patches? What's the next step. > > If you could look at the rename that would be great. Pa

Re: python CFFI bindings integration into notmuch build/test

On Thu 14 Nov 2019 at 23:24 +0100, Floris Bruynooghe wrote: > On Thu 14 Nov 2019 at 22:20 +0200, Tomi Ollila wrote: >> In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi >> which contains related changes -- You can fetch the code while waiting >> f

Re: python CFFI bindings integration into notmuch build/test

On Thu 14 Nov 2019 at 22:20 +0200, Tomi Ollila wrote: > In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi > which contains related changes -- You can fetch the code while waiting > for more collaboration instructions from David. Aha, thanks! Floris

Re: python CFFI bindings integration into notmuch build/test

Hi, Thanks for carrying on with this! I'm a little confused with how to follow this, is the current state of the code somewhere in a repo/branch where I can try things out and make changes from? On Tue 05 Nov 2019 at 22:22 -0400, David Bremner wrote: > Tomi Ollila writes: > > >> alternative:

Re: Python3 cffi bindings

On Tue 22 Oct 2019 at 13:32 -0300, David Bremner wrote: > David Bremner writes: > >> The LD_LIBRARY_PATH is already set by the test harness, as is PATH (to >> find notmuch). It looks like your function notmuch is not respecting >> PATH (see attached log). if I hack something like >> >> diff

Re: Python3 cffi bindings

On Mon 14 Oct 2019 at 09:42 -0300, David Bremner wrote: > David Bremner writes: > >> The shim in >> T391-python-cffi.sh doesn't work for me, it doesn't manage to set >> PYTHONPATH so that notdb is importable. Ah yes, I tested this shim while activating a venv with the extension installed using

Re: Python3 cffi bindings

On Tue 08 Oct 2019 at 19:24 -0300, David Bremner wrote: > Floris Bruynooghe writes: >> Anyway, I found the code, checked things work, updated tests on new >> python versions, added a very basic intergration with the test >> framework and squashed the commits. Otherwi

Python3 cffi bindings

Hi all, IIRC there was a thread in August about another attempt at bringing the CFFI-based bindings on board as a Python3-only version. I believe there was a desire to re-name things but my searching-fu is failing me and I can no longer find the email thread. Anyway, I found the code, checked

Re: segfault using python bindings

On Wed 21 Aug 2019 at 12:02 -0400, Daniel Kahn Gillmor wrote: > On Tue 2019-08-20 19:20:30 +0200, Floris Bruynooghe wrote: >> For path series what did you have in mind? One single patch with the >> whole lot? The original history at https:://github/flub/notdb? >> Someth

Re: segfault using python bindings

On Thu 15 Aug 2019 at 09:28 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> On Wed 14 Aug 2019 at 16:20 -0300, David Bremner wrote: >>> >>> Can you remind me what the percieved blockers are for merging into the >>> main notmuch tree? I'm less

Re: segfault using python bindings

On Wed 14 Aug 2019 at 16:20 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> These are at https://github.com/flub/notmuch/tree/cffi/bindings/python-cffi >> >> I'm not really convinced of the way forward last time it was discussed >> on how to get them

Re: segfault using python bindings

On Fri 16 Nov 2018 at 07:15 -0500, Daniel Kahn Gillmor wrote: > On Fri 2018-11-16 06:27:12 -0400, David Bremner wrote: >> Floris Bruynooghe writes: >> >>> These are at https://github.com/flub/notmuch/tree/cffi/bindings/python-cffi >>> >>> I'm not rea

Re: segfault using python bindings

On Fri 16 Nov 2018 at 06:29 -0400, David Bremner wrote: > Brian May writes: > >> Floris Bruynooghe writes: >> >>> I've since wondered if just getting them standalone on pypi is perhaps a >>> useful service in the mean time as it's relatively little

Re: segfault using python bindings

Hi, On Sun 11 Nov 2018 at 16:16 -0400, David Bremner wrote: > David Čepelík writes: > >> Hello Notmuch devs, >> >> I'm facing an issue trying to use the Python bindings. This trivial >> piece of code segfaults: >> >> import notmuch > > I don't remember the details [1], but there are known

Re: [PATCH 2/2] test: pytest runner for the test suite

On Sun 08 Apr 2018 at 19:14 -0300, David Bremner wrote: > Floris Bruynooghe <f...@devork.be> writes: > >> This series looks good to me, would be great to have! Do you want to >> commit them this or should I just incorporate it and submit together >> with tests once

Re: [PATCH 2/2] test: pytest runner for the test suite

This series looks good to me, would be great to have! Do you want to commit them this or should I just incorporate it and submit together with tests once actual tests exist. You could always commit with a ``def test_dummy(): assert True`` or something if you like. Thanks! Floris On Sat 07 Apr

experimenting with pytest tests

Hi, From another conversation on this list I've dug up my earlier attempts at integrating a pytest run into the notmuch testing suite. I'd be grateful for some guidance on whether this is the right way to go about things. Here's the diff of configure: diff --git a/configure b/configure index

Re: New Python bindings (was: Crash with Python bindings)

On Wed, Mar 28 2018, David Bremner wrote: > Brian May writes: > >> I can into this thread late. However, my priorities for python bindings >> would be: > > [...] >> * Packages should be available from pypi.python.org >> > > We tried this before, and it didn't work out

Re: New Python bindings (was: Crash with Python bindings)

On Wed, Mar 28 2018, Brian May wrote: > Justus Winter writes: > >>> This is exactly what I have fixed in my alternative bindings which I >>> created around the end of last year [0]. So we do have an idea of how >>> to fix this, at the time I said I do believe that it's

Re: New Python bindings

On Wed, Mar 28 2018, Justus Winter wrote: > Floris Bruynooghe <f...@devork.be> writes: > >> On Wed, Mar 21 2018, Justus Winter wrote: >>> >>> Floris Bruynooghe <f...@devork.be> writes: >>> >>>> This is exactly what I have fixed

Re: pytest integration for the notmuch test suite

On Sun, Mar 25 2018, David Bremner wrote: > Here's one approach. A given pytest "file" can be embedded in a normal > (for us) test script. As I write this, it occurs to me you might be > thinking of embedding unit tests in the bindings source files; that > would be easy to add, something along

Re: [PATCH 1/3] configure: check for pytest binary

On Sun, Mar 25 2018, David Bremner wrote: > This is to support future use of pytest in the test suite Thanks for having a go at this! > --- > configure | 24 > 1 file changed, 24 insertions(+) > > diff --git a/configure b/configure > index b177b141..ab45878d 100755 >

Re: New Python bindings (was: Crash with Python bindings)

On Wed, Mar 21 2018, Justus Winter wrote: > > Floris Bruynooghe <f...@devork.be> writes: > >> This is exactly what I have fixed in my alternative bindings which I >> created around the end of last year [0]. So we do have an idea of how >> to fix this, at the t

Re: Crash with Python bindings

Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > On Fri 2018-03-16 19:30:37 +0100, Floris Bruynooghe wrote: >> If someone can hook pytest runs with various python versions into the >> notmuch test suit I'd be very much obliged and probably have another go >

Re: Crash with Python bindings

Hi all, David Bremner writes: > "W. Trevor King" writes: > >> you can avoid the abort (which happens when q.__del__ is called after >> db.__del__). We could make that sort of cleanup easier with context >> managers for Query objects (we have them for

LIBNOTMUCH_MINOR_VERSION for 0.26

Hi, I was looking to update my bindings with the latest release and am somewhat confused on the value of the LIBNOTMUCH_MINOR_VERSION value. It seems to be suggested in e.g. the documentation of notmuch_database_index_file that for notmuch 0.26 this should be 1, however the header still seems to

Re: Update on python-cffi bindings

Hi all, Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > On Thu 2017-12-21 12:30:39 +0100, Floris Bruynooghe wrote: >> The API changes a lot and there is no easy migration. And history has >> shown that's a terrible way to get something new adopted. Last time I &g

  1   2   >