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. > --- >

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

2020-07-11 Thread David Bremner
A seperate conf.py and doc directory will be needed if someone wants to build the bindings docs separately from notmuch. --- configure | 4 doc/conf.py | 8 doc/index.rst | 1 + doc/python-bindings.rst | 5 + 4 files changed, 18 insertions(+)

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

status of the new python bindings

2020-05-07 Thread Anton Khirnov
Hi, I've started tinkering with the "new" Python bindings (python-cffi / python-notmuch2) and have a couple questions/comments about them: 1) What is the logic behind choosing whether something is exported as a property or as a method? E.g. Database.needs_upgrade is a prope

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

2018-04-04 Thread Brian May
shared library SONAME. If this is not the case, ignore the rest of this email. Ideally the python bindings should be in a git repository that is separate from the C library. This means you don't have to release new python bindings for every new source code release of notmuch. You only need to make a new release if su

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

2018-03-28 Thread David Bremner
Brian May writes: > David Bremner writes: > >> We tried this before, and it didn't work out very well. Bindings tend to >> depend on a strict matching of versions with the underlying library, so >> distributing them seperately doesn't really make

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

2018-03-28 Thread Brian May
David Bremner writes: > We tried this before, and it didn't work out very well. Bindings tend to > depend on a strict matching of versions with the underlying library, so > distributing them seperately doesn't really make sense to me. You need > the underlying libraries, so

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 writes: > >> On Wed, Mar 21 2018, Justus Winter wrote: >>> >>> Floris Bruynooghe writes: >>> This is exactly what I have fixed in my alternative bindings which I created around the end of

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

2018-03-28 Thread David Bremner
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 very well. Bindings tend to depend on a strict matching of

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

2018-03-28 Thread Brian May
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 possible to also >> do this for the existing

Re: New Python bindings

2018-03-27 Thread Justus Winter
Floris Bruynooghe writes: > On Wed, Mar 21 2018, Justus Winter wrote: >> >> Floris Bruynooghe 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

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 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

New Python bindings (was: Crash with Python bindings)

2018-03-21 Thread Justus Winter
Hi Floris :) Floris Bruynooghe 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 possible to also > do this for the

[PATCH 4/6] test: Add tests for new python bindings

2017-12-07 Thread l-m-h
The tests where adopted from the tests for the corresponding C functions in test/T590-libconfig.sh. --- test/T390-python.sh | 68 + 1 file changed, 68 insertions(+) diff --git a/test/T390-python.sh b/test/T390-python.sh index