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

2020-07-14 Thread Floris Bruynooghe
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

2020-07-14 Thread Floris Bruynooghe
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.

2020-07-14 Thread Floris Bruynooghe
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

2020-07-14 Thread Floris Bruynooghe
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

2020-07-08 Thread Floris Bruynooghe
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

2020-07-08 Thread Floris Bruynooghe
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

2020-07-08 Thread Floris Bruynooghe
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

2020-07-04 Thread Floris Bruynooghe
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

2020-07-04 Thread Floris Bruynooghe
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

2020-06-29 Thread Floris Bruynooghe
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.

2020-06-29 Thread Floris Bruynooghe
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

2020-06-28 Thread Floris Bruynooghe
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

2020-06-28 Thread Floris Bruynooghe
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

2020-06-23 Thread Floris Bruynooghe
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

2020-06-22 Thread Floris Bruynooghe
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

2020-06-22 Thread Floris Bruynooghe
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

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

2020-06-19 Thread Floris Bruynooghe
On Fri 19 Jun 2020 at 07:20 -0300, David Bremner wrote: > Floris Bruynooghe writes: > BTW I noticed something (setuptools?) translates "0.30~rc2" to > "0.30-rc2". I assume that is as intended, and there are some stricter > rules for python module versions. I

python/notmuch2 on PyPI

2020-06-19 Thread Floris Bruynooghe
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

2020-06-19 Thread Floris Bruynooghe
().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

2020-06-19 Thread Floris Bruynooghe
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

2020-06-19 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-15 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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

2020-06-14 Thread Floris Bruynooghe
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?

2020-06-05 Thread Floris Bruynooghe
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

2020-06-02 Thread Floris Bruynooghe
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?

2020-05-25 Thread Floris Bruynooghe
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

2020-05-23 Thread Floris Bruynooghe
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

2020-05-21 Thread Floris Bruynooghe
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

2020-05-21 Thread Floris Bruynooghe
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

2019-11-18 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-17 Thread Floris Bruynooghe
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

2019-11-14 Thread Floris Bruynooghe
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

2019-11-14 Thread Floris Bruynooghe
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

2019-11-14 Thread Floris Bruynooghe
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

2019-10-25 Thread Floris Bruynooghe
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

2019-10-17 Thread Floris Bruynooghe
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

2019-10-09 Thread Floris Bruynooghe
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

2019-10-08 Thread Floris Bruynooghe
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

2019-08-26 Thread Floris Bruynooghe
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

2019-08-20 Thread Floris Bruynooghe
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

2019-08-15 Thread Floris Bruynooghe
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

2018-11-16 Thread Floris Bruynooghe
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

2018-11-16 Thread Floris Bruynooghe
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

2018-11-15 Thread Floris Bruynooghe
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

2018-04-13 Thread Floris Bruynooghe
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

2018-04-08 Thread Floris Bruynooghe
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

2018-04-07 Thread Floris Bruynooghe
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)

2018-03-28 Thread Floris Bruynooghe
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)

2018-03-28 Thread Floris Bruynooghe
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

2018-03-28 Thread Floris Bruynooghe
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

2018-03-26 Thread Floris Bruynooghe
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

2018-03-26 Thread Floris Bruynooghe
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)

2018-03-26 Thread Floris Bruynooghe
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

2018-03-18 Thread Floris Bruynooghe
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

2018-03-16 Thread Floris Bruynooghe
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

2018-01-15 Thread Floris Bruynooghe
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: [PATCH] NEWS: library changes for 0.26

2017-12-30 Thread Floris Bruynooghe
David Bremner writes: > These are just "my" changes, as arbited by "git shortlog", which > sometimes lies. > --- > NEWS | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/NEWS b/NEWS > index 3b6404e7..1c5edf4c 100644 > --- a/NEWS > +++ b/NEWS > @@

Re: Update on python-cffi bindings

2017-12-29 Thread Floris Bruynooghe
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

Re: Update on python-cffi bindings

2017-12-21 Thread Floris Bruynooghe
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > Hi Floris-- > > On Sun 2017-12-17 19:08:18 +0100, Floris Bruynooghe wrote: > > i've heard reported, and i also appreciate your attention to performance > concerns on different python platforms (e.g. making sure things

Update on python-cffi bindings

2017-12-17 Thread Floris Bruynooghe
Hi all, Thanks for all the feedback on an early post of my CFFI-based libnotmuch Python bindings. I've now completed these somewhat more and they now have most of the functionality. Here's what's new since last time: - All tests pass on Python 3.5, 3.6 and pypy3.5 I could probably add 3.4

Re: DRAFT Introduce CFFI-based Python bindings

2017-12-01 Thread Floris Bruynooghe
Florian Klink writes: >>> I guess you'll have to convince the maintainers / users of alot and afew >>> that this makes sense before we go much further. I'd point out that >>> Debian stable is only at python 3.5, so that makes me a bit wary of this >>> (being able to run the

Re: [PATCH] python: add bindings for notmuch_message_get_propert(y/ies)

2017-11-29 Thread Floris Bruynooghe
Daniel Kahn Gillmor writes: > On Tue 2017-11-28 23:46:11 +0100, Ruben Pollan wrote: >> Message.get_property (prop) returns a string with the value of the property >> and >> Message.get_properties (prop, exact=False) returns a list [(key, value)] > > This looks like a

Re: DRAFT Introduce CFFI-based Python bindings

2017-11-29 Thread Floris Bruynooghe
Patrick Totzke <patricktot...@gmail.com> writes: > Quoting David Bremner (2017-11-28 23:59:26) >> Floris Bruynooghe <f...@devork.be> writes: >> >> > >> > Lastly there are some downsides to the choices I made: >> > - I ended up going square

Re: DRAFT Introduce CFFI-based Python bindings

2017-11-29 Thread Floris Bruynooghe
David Bremner <da...@tethera.net> writes: > Floris Bruynooghe <f...@devork.be> writes: > >> >> Lastly there are some downsides to the choices I made: >> - I ended up going squarely for CPython 3.6+. Choosing Python >> 3 allowed better API design,

[PATCH] Introduce CFFI-based python bindings

2017-11-28 Thread Floris Bruynooghe
From: Floris Bruynooghe <f...@google.com> This introduces the beginnings of new CFFI-based Python bindings. The bindings aim at: - Better performance on pypy - Easier to use Python-C interface - More "pythonic" - The API should not allow invalid operations - Use native objec

DRAFT Introduce CFFI-based Python bindings

2017-11-28 Thread Floris Bruynooghe
Hi all, Here are the beginnings off CFFI-based Python bindings, rather than the ctypes-based ones currently available. I started this work in order to get faster bindings on pypy since a script of mine was running slower on pypy than CPython. Initially aiming for a drop-in replacement of the