[notmuch] SWIG (and particularly Python) bindings

[Carl Worth]

On Wed, 30 Dec 2009 11:52:23 +0100, Adrian Perez de Castro  wrote:
> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere.

Yes. As soon as we have users of the library we can install it as a
shared library.

>  One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).

Totally uninterested in libtool personally. It does so many things wrong
(.la files that *only* cause breakage on Linux, a tendency to shove
hard-coded rpath entries in the library where unwanted), and doesn't
seem to do much of anything that's really interesting. I'm happy to just
accept patches that tweak the command in the Makefile for "build a
shared library now" for each platform that's of practical interest. The
job here is just not that complicated.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] SWIG (and particularly Python) bindings

[Carl Worth]

On Tue, 29 Dec 2009 04:16:43 -0500, Ben Gamari  wrote:
> I've been looking at switching away from sup recently to something with
> a slightly little less everything-and-the-kitchen-sink philosophy.

Hi Ben,

Welcome to Notmuch!

> Notmuch looks excellent, although it appears that its current front-end
> for my editor of choice (vim) is a little lacking in some ways
> (operations involving a call to notmuch invariably lock up vi for the
> duration of the operation).

Yes. The emacs mode was similarly crippled initially and fairly painful
until we fixed that, (and quite nice afterwards).

> these are to be included in-tree, I would be curious to hear people have
> to say about how we might integrate it into the sup build system.

I can't say much about integrating with the sup build system...

;-)

> Hope this helps someone. I'll hopefully have a chance to work with the
> bindings soon and will send a new set of patches once I think I've found
> all of the obvious issues.

Thanks for sharing. I'll look forward to future contributions from you!

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Carl Worth's message of Wed Jan 20 03:45:34 -0500 2010:
> Welcome to Notmuch!
> 
Thanks!

> > Notmuch looks excellent, although it appears that its current front-end
> > for my editor of choice (vim) is a little lacking in some ways
> > (operations involving a call to notmuch invariably lock up vi for the
> > duration of the operation).
> 
> Yes. The emacs mode was similarly crippled initially and fairly painful
> until we fixed that, (and quite nice afterwards).
> 
I can easily believe that. I've tried using the vim mode and quickly
gave up. I think I'm going to have to stick with sup until I've added
the appropriate subprocess support into vim. I have some half-completed
code, but still have a ways to go.

> > these are to be included in-tree, I would be curious to hear people have
> > to say about how we might integrate it into the sup build system.
> 
> I can't say much about integrating with the sup build system...
> 
Heh. My bad.

- Ben

Re: [notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Carl Worth's message of Wed Jan 20 03:45:34 -0500 2010:
> Welcome to Notmuch!
> 
Thanks!

> > Notmuch looks excellent, although it appears that its current front-end
> > for my editor of choice (vim) is a little lacking in some ways
> > (operations involving a call to notmuch invariably lock up vi for the
> > duration of the operation).
> 
> Yes. The emacs mode was similarly crippled initially and fairly painful
> until we fixed that, (and quite nice afterwards).
> 
I can easily believe that. I've tried using the vim mode and quickly
gave up. I think I'm going to have to stick with sup until I've added
the appropriate subprocess support into vim. I have some half-completed
code, but still have a ways to go.

> > these are to be included in-tree, I would be curious to hear people have
> > to say about how we might integrate it into the sup build system.
> 
> I can't say much about integrating with the sup build system...
> 
Heh. My bad.

- Ben
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] SWIG (and particularly Python) bindings

[Carl Worth]

On Wed, 30 Dec 2009 11:52:23 +0100, Adrian Perez de Castro  
wrote:
> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere.

Yes. As soon as we have users of the library we can install it as a
shared library.

>  One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).

Totally uninterested in libtool personally. It does so many things wrong
(.la files that *only* cause breakage on Linux, a tendency to shove
hard-coded rpath entries in the library where unwanted), and doesn't
seem to do much of anything that's really interesting. I'm happy to just
accept patches that tweak the command in the Makefile for "build a
shared library now" for each platform that's of practical interest. The
job here is just not that complicated.

-Carl


pgpyJxIH2dyDj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] SWIG (and particularly Python) bindings

[Carl Worth]

On Tue, 29 Dec 2009 04:16:43 -0500, Ben Gamari  wrote:
> I've been looking at switching away from sup recently to something with
> a slightly little less everything-and-the-kitchen-sink philosophy.

Hi Ben,

Welcome to Notmuch!

> Notmuch looks excellent, although it appears that its current front-end
> for my editor of choice (vim) is a little lacking in some ways
> (operations involving a call to notmuch invariably lock up vi for the
> duration of the operation).

Yes. The emacs mode was similarly crippled initially and fairly painful
until we fixed that, (and quite nice afterwards).

> these are to be included in-tree, I would be curious to hear people have
> to say about how we might integrate it into the sup build system.

I can't say much about integrating with the sup build system...

;-)

> Hope this helps someone. I'll hopefully have a chance to work with the
> bindings soon and will send a new set of patches once I think I've found
> all of the obvious issues.

Thanks for sharing. I'll look forward to future contributions from you!

-Carl


pgpioF2deCOD3.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Scott Robinson's message of Wed Dec 30 06:34:15 -0500 2009:
> Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 
> 2009:
> > BTW, I think that if more bindings start to appear, Notmuch might be built
> > as a shared library, to avoid duplicating it everywhere. One option may be
> > using *just* libtool but not the rest of auto-foo tools (for the record:
> > I agree with Carl that they are slow and wicked).
> 
> http://github.com/quad/notmuch/tree/libtool

Is this branch being considered for merge? The build output arguably
isn't as pretty as it was before, but it seems to work. Moreover, my
SWIG patches currently depend upon having a shared library involved.

- Ben

Re: [notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Scott Robinson's message of Wed Dec 30 06:34:15 -0500 2009:
> Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 
> 2009:
> > BTW, I think that if more bindings start to appear, Notmuch might be built
> > as a shared library, to avoid duplicating it everywhere. One option may be
> > using *just* libtool but not the rest of auto-foo tools (for the record:
> > I agree with Carl that they are slow and wicked).
> 
> http://github.com/quad/notmuch/tree/libtool

Is this branch being considered for merge? The build output arguably
isn't as pretty as it was before, but it seems to work. Moreover, my
SWIG patches currently depend upon having a shared library involved.

- Ben
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] SWIG (and particularly Python) bindings

[Adrian Perez de Castro]

On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:

> Regardless, I thought it might be nice to have access to the notmuch
> backend from a language other than C (preferably my high-level language
> of choice, python) [...]

Funny, I was just doing the same: a Python binding. Haha, so now we have
two just-backed Python bindings. What should we do?

> [...] To this end, I took a few hours today acquainting
> myself with SWIG and produced these bindings for Python. Unfortunately,
> it doesn't appear that SWIG has particularly good support for
> object-oriented C [...]

I already used SWIG sometimes in the past (and did not like it a lot), so
my binding is using Cython [*] (which is exactly like Pyrex plus some extra
features), so the binding is partly manual.

> While the bindings are currently in the form of a patch to notmuch
> (creating a top-level swig directory in the source tree), they could
> certainly be moved out-of-tree if the powers that be don't feel it
> appropriate to include them. [...]

Same here, see attached patch. It is currently unfinished, and I was just
about to add support for iterating notmuch_threads_t and other similar
structures. I can also publish a Git repo with the entire branch, just
drop me a line if you want me to do that.

> [...] Unfortunately, the build system is currently almost entirely
> independent from the notmuch build system. If  these are to be
> included in-tree, I would be curious to hear people have
> to say about how we might integrate it into the sup build system.
  ^^^
(Mmmh, I suppose you mean "notmuch build system" there :P)

Mine is a little more cooked, as I have added a distutils "setup.py"
script. The bad news is that Python modules need to be compiled as
relocatable object files (-fPIC to teh rescue!), and the linker will
refuse to link the generated code with "notmuch.a" -- so I am instructing
distutils to compile *all* sources again. Not nice.

BTW, I think that if more bindings start to appear, Notmuch might be built
as a shared library, to avoid duplicating it everywhere. One option may be
using *just* libtool but not the rest of auto-foo tools (for the record:
I agree with Carl that they are slow and wicked).

Regards,


[*] http://www.cython.org/
-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: notmuch-python-wip.patch
Type: text/x-patch
Size: 16874 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

[notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Adrian Perez de Castro's message of Wed Dec 30 05:52:23 -0500 
2009:
> On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:
> 
> > Regardless, I thought it might be nice to have access to the notmuch
> > backend from a language other than C (preferably my high-level language
> > of choice, python) [...]
> 
> Funny, I was just doing the same: a Python binding. Haha, so now we have
> two just-backed Python bindings. What should we do?

Heh, it's a small world, eh?

> 
> > [...] To this end, I took a few hours today acquainting
> > myself with SWIG and produced these bindings for Python. Unfortunately,
> > it doesn't appear that SWIG has particularly good support for
> > object-oriented C [...]
> 
> I already used SWIG sometimes in the past (and did not like it a lot), so
> my binding is using Cython [*] (which is exactly like Pyrex plus some extra
> features), so the binding is partly manual.
> 
I liked that SWIG would give us coverage for a multitude of languages
with little work. Unfortunately, getting an object oriented interface
requires wrapping the functions exposed by SWIG. Nevertheless, I think
being able to generically hide the ugliness of the binding glue itself
is quite nice. Moveover, there's effectively no SWIG interface code to
maintain.  It's literally just a [#%]include "notmuch.h". The rest is
all the Python wrapper. This seems like a nice binding model, short of
SWIG doing everything (the developers at some point might add support
for proper wrapping of object-oriented C code).

> > While the bindings are currently in the form of a patch to notmuch
> > (creating a top-level swig directory in the source tree), they could
> > certainly be moved out-of-tree if the powers that be don't feel it
> > appropriate to include them. [...]
> 
> Same here, see attached patch. It is currently unfinished, and I was just
> about to add support for iterating notmuch_threads_t and other similar
> structures. I can also publish a Git repo with the entire branch, just
> drop me a line if you want me to do that.
> 
In my approach, I just used the iterator protocol.

> > [...] Unfortunately, the build system is currently almost entirely
> > independent from the notmuch build system. If  these are to be
> > included in-tree, I would be curious to hear people have
> > to say about how we might integrate it into the sup build system.
>   ^^^
> (Mmmh, I suppose you mean "notmuch build system" there :P)

Heh, yep.

> 
> Mine is a little more cooked, as I have added a distutils "setup.py"
> script. The bad news is that Python modules need to be compiled as
> relocatable object files (-fPIC to teh rescue!), and the linker will
> refuse to link the generated code with "notmuch.a" -- so I am instructing
> distutils to compile *all* sources again. Not nice.
> 
In my patch I simple I modified the LDFLAGS to include -fPIC. Not sure if
that's an acceptable option or not.

> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere. One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).
> 
I think you're probably right. Libtool is probably the best option here
(Despite the fact that I, too, have a bitter hatred of autotools).

Cheers,
- Ben

Re: [notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Excerpts from Adrian Perez de Castro's message of Wed Dec 30 05:52:23 -0500 
2009:
> On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:
> 
> > Regardless, I thought it might be nice to have access to the notmuch
> > backend from a language other than C (preferably my high-level language
> > of choice, python) [...]
> 
> Funny, I was just doing the same: a Python binding. Haha, so now we have
> two just-backed Python bindings. What should we do?

Heh, it's a small world, eh?

> 
> > [...] To this end, I took a few hours today acquainting
> > myself with SWIG and produced these bindings for Python. Unfortunately,
> > it doesn't appear that SWIG has particularly good support for
> > object-oriented C [...]
> 
> I already used SWIG sometimes in the past (and did not like it a lot), so
> my binding is using Cython [*] (which is exactly like Pyrex plus some extra
> features), so the binding is partly manual.
> 
I liked that SWIG would give us coverage for a multitude of languages
with little work. Unfortunately, getting an object oriented interface
requires wrapping the functions exposed by SWIG. Nevertheless, I think
being able to generically hide the ugliness of the binding glue itself
is quite nice. Moveover, there's effectively no SWIG interface code to
maintain.  It's literally just a [#%]include "notmuch.h". The rest is
all the Python wrapper. This seems like a nice binding model, short of
SWIG doing everything (the developers at some point might add support
for proper wrapping of object-oriented C code).

> > While the bindings are currently in the form of a patch to notmuch
> > (creating a top-level swig directory in the source tree), they could
> > certainly be moved out-of-tree if the powers that be don't feel it
> > appropriate to include them. [...]
> 
> Same here, see attached patch. It is currently unfinished, and I was just
> about to add support for iterating notmuch_threads_t and other similar
> structures. I can also publish a Git repo with the entire branch, just
> drop me a line if you want me to do that.
> 
In my approach, I just used the iterator protocol.

> > [...] Unfortunately, the build system is currently almost entirely
> > independent from the notmuch build system. If  these are to be
> > included in-tree, I would be curious to hear people have
> > to say about how we might integrate it into the sup build system.
>   ^^^
> (Mmmh, I suppose you mean "notmuch build system" there :P)

Heh, yep.

> 
> Mine is a little more cooked, as I have added a distutils "setup.py"
> script. The bad news is that Python modules need to be compiled as
> relocatable object files (-fPIC to teh rescue!), and the linker will
> refuse to link the generated code with "notmuch.a" -- so I am instructing
> distutils to compile *all* sources again. Not nice.
> 
In my patch I simple I modified the LDFLAGS to include -fPIC. Not sure if
that's an acceptable option or not.

> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere. One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).
> 
I think you're probably right. Libtool is probably the best option here
(Despite the fact that I, too, have a bitter hatred of autotools).

Cheers,
- Ben
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] SWIG (and particularly Python) bindings

[Scott Robinson]

Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 
2009:
> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere. One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).

http://github.com/quad/notmuch/tree/libtool
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] SWIG (and particularly Python) bindings

[Scott Robinson]

Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 
2009:
> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere. One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).

http://github.com/quad/notmuch/tree/libtool
-- 
Scott Robinson | http://quadhome.com/

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/

Re: [notmuch] SWIG (and particularly Python) bindings

[Adrian Perez de Castro]

On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:

> Regardless, I thought it might be nice to have access to the notmuch
> backend from a language other than C (preferably my high-level language
> of choice, python) [...]

Funny, I was just doing the same: a Python binding. Haha, so now we have
two just-backed Python bindings. What should we do?

> [...] To this end, I took a few hours today acquainting
> myself with SWIG and produced these bindings for Python. Unfortunately,
> it doesn't appear that SWIG has particularly good support for
> object-oriented C [...]

I already used SWIG sometimes in the past (and did not like it a lot), so
my binding is using Cython [*] (which is exactly like Pyrex plus some extra
features), so the binding is partly manual.

> While the bindings are currently in the form of a patch to notmuch
> (creating a top-level swig directory in the source tree), they could
> certainly be moved out-of-tree if the powers that be don't feel it
> appropriate to include them. [...]

Same here, see attached patch. It is currently unfinished, and I was just
about to add support for iterating notmuch_threads_t and other similar
structures. I can also publish a Git repo with the entire branch, just
drop me a line if you want me to do that.

> [...] Unfortunately, the build system is currently almost entirely
> independent from the notmuch build system. If  these are to be
> included in-tree, I would be curious to hear people have
> to say about how we might integrate it into the sup build system.
  ^^^
(Mmmh, I suppose you mean "notmuch build system" there :P)

Mine is a little more cooked, as I have added a distutils "setup.py"
script. The bad news is that Python modules need to be compiled as
relocatable object files (-fPIC to teh rescue!), and the linker will
refuse to link the generated code with "notmuch.a" -- so I am instructing
distutils to compile *all* sources again. Not nice.

BTW, I think that if more bindings start to appear, Notmuch might be built
as a shared library, to avoid duplicating it everywhere. One option may be
using *just* libtool but not the rest of auto-foo tools (for the record:
I agree with Carl that they are slow and wicked).

Regards,


[*] http://www.cython.org/
-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
 Makefile  |1 +
 python/.gitignore |2 +
 python/Makefile   |6 +
 python/Makefile.local |   15 ++
 python/notmuch.pyx|  397 +
 python/pyutil.h   |   16 ++
 python/setup.py   |   89 +++
 7 files changed, 526 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 021fdb8..081d670 100644
--- a/Makefile
+++ b/Makefile
@@ -37,6 +37,7 @@ include Makefile.config
 
 include lib/Makefile.local
 include compat/Makefile.local
+include python/Makefile.local
 include Makefile.local
 
 # The user has not set any verbosity, default to quiet mode and inform the
diff --git a/python/.gitignore b/python/.gitignore
new file mode 100644
index 000..7f0efa8
--- /dev/null
+++ b/python/.gitignore
@@ -0,0 +1,2 @@
+notmuch.c
+build/
diff --git a/python/Makefile b/python/Makefile
new file mode 100644
index 000..e1e5c43
--- /dev/null
+++ b/python/Makefile
@@ -0,0 +1,6 @@
+
+all: python
+
+%:
+	make -C .. $@
+
diff --git a/python/Makefile.local b/python/Makefile.local
new file mode 100644
index 000..140a701
--- /dev/null
+++ b/python/Makefile.local
@@ -0,0 +1,15 @@
+dir=python
+
+python: $(dir)/build/.stamp
+	(cd $(dir) && python setup.py build)
+	touch $@
+
+$(dir)/build/.stamp: lib/notmuch.a
+
+clean: clean-python
+
+clean-python:
+	$(RM) -r $(dir)/build
+
+.PHONY: clean-python python
+
diff --git a/python/notmuch.pyx b/python/notmuch.pyx
new file mode 100644
index 000..f38b719
--- /dev/null
+++ b/python/notmuch.pyx
@@ -0,0 +1,397 @@
+#! /usr/bin/env python
+# -*- coding: utf-8 -*-
+# vim: fenc=utf-8 ft=pyrex
+#
+# Copyright © 2009 Adrian Perez 
+#
+# Distributed under terms of the GPLv3 license.
+#
+
+cdef extern from "talloc.h":
+	void* talloc_init(char *fmt, ...)
+	int   talloc_free(void *ctx)
+
+
+cdef extern from "pyutil.h":
+	#
+	# Utility macros
+	#
+	char** pyutil_alloc_strv(void *ctx, unsigned nitems)
+
+
+cdef extern from "notmuch.h":
+	#
+	# Return status handling
+	#
+	ctypedef enum notmuch_status_t:
+		NOTMUCH_STATUS_SUCCESS
+		NOTMUCH_STATUS_OUT_OF_MEMORY
+		NOTMUCH_STATUS_READONLY_DATABASE
+		NOTMUCH_STATUS_XAPIAN_EXCEPTION
+		NOTMUCH_STATUS_FILE_ERROR
+		NOTMUCH_STATUS_FILE_NOT_EMAIL
+		NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID
+		NOTMUCH_STATUS_NULL_POINTER
+		NOTMUCH_STATUS_TAG_TOO_LONG
+		NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW
+
+	char* notmuch_status_to_string(notmuch_status_t status)
+
+	#
+	# notmuch_database_* -> notmuch.Database
+	#
+	ctypedef enum notmuch_database_mode_t:
+		NOTMUCH_DATABASE_MODE_READ_ONLY
+		NOTMUCH_DATABASE_MODE_READ_WRITE
+
+	ctypedef enum notmuch_sort_t:
+		NO

[notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Hey all,

I've been looking at switching away from sup recently to something with
a slightly little less everything-and-the-kitchen-sink philosophy.
Notmuch looks excellent, although it appears that its current front-end
for my editor of choice (vim) is a little lacking in some ways
(operations involving a call to notmuch invariably lock up vi for the
duration of the operation).

Regardless, I thought it might be nice to have access to the notmuch
backend from a language other than C (preferably my high-level language
of choice, python). To this end, I took a few hours today acquainting
myself with SWIG and produced these bindings for Python. Unfortunately,
it doesn't appear that SWIG has particularly good support for
object-oriented C, so the approach I took was using SWIG to generate the
low-level glue, on top of which I wrote a properly structured set of
Python bindings. While I theoretically have full interface coverage,
I unfortunately haven't had a chance to use these for anything useful,
so who knows whether much of it actually works. Regardless, I thought
folks might be interested.

While the bindings are currently in the form of a patch to notmuch
(creating a top-level swig directory in the source tree), they could
certainly be moved out-of-tree if the powers that be don't feel it
appropriate to include them. Unfortunately, the build system is
currently almost entirely independent from the notmuch build system. If
these are to be included in-tree, I would be curious to hear people have
to say about how we might integrate it into the sup build system.

Hope this helps someone. I'll hopefully have a chance to work with the
bindings soon and will send a new set of patches once I think I've found
all of the obvious issues.

- Ben


---
 swig/Makefile|   18 
 swig/notmuch.py  |  222 ++
 swig/notmuch_funcs.i |9 ++
 3 files changed, 249 insertions(+), 0 deletions(-)
 create mode 100644 swig/Makefile
 create mode 100644 swig/notmuch.py
 create mode 100644 swig/notmuch_funcs.i

diff --git a/swig/Makefile b/swig/Makefile
new file mode 100644
index 000..c01c427
--- /dev/null
+++ b/swig/Makefile
@@ -0,0 +1,18 @@
+include ../Makefile.config
+
+INCLUDES=-I../lib -I/usr/include/python2.6
+CFLAGS=${INCLUDES}
+
+all : python
+
+python : _notmuch_funcs.so notmuch.py
+
+_notmuch_funcs.so : notmuch_funcs_wrap.o
+   g++ -shared ${XAPIAN_LDFLAGS} ${GMIME_LDFLAGS} ${TALLOC_LDFLAGS} -o $@ 
$< ../lib/notmuch.a
+
+%_wrap.o : %_wrap.c
+   gcc ${CFLAGS} -fPIC -c -o $@ $<
+
+%_wrap.c %.py : %.i 
+   swig -python ${INCLUDES} $<
+
diff --git a/swig/notmuch.py b/swig/notmuch.py
new file mode 100644
index 000..95b81ad
--- /dev/null
+++ b/swig/notmuch.py
@@ -0,0 +1,222 @@
+import notmuch_funcs as nm
+from datetime import datetime
+
+class Exception(Exception):
+def get_message():
+errors = {
+nm.NOTMUCH_STATUS_OUT_OF_MEMORY: 'out of memory',
+nm.NOTMUCH_STATUS_READONLY_DATABASE: 'database opened 
as read-only',
+nm.NOTMUCH_STATUS_XAPIAN_EXCEPTION: 'xapian error',
+nm.NOTMUCH_STATUS_FILE_ERROR: 'file error',
+nm.NOTMUCH_STATUS_FILE_NOT_EMAIL: 'file not email 
message',
+nm.NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: 'duplicate 
message id',
+nm.NOTMUCH_STATUS_NULL_POINTER: 'null pointer',
+nm.NOTMUCH_STATUS_TAG_TOO_LONG: 'tag name too long',
+nm.NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW: 'unbalanced 
freeze/thaw',
+}
+return errors.get(self.status, 'unknown error')
+
+def __init__(self, status):
+self.status = status
+
+def _handle_status(status):
+if (status != nm.NOTMUCH_STATUS_SUCCESS):
+raise Exception(status)
+
+class Database(object):
+MODE_READ_ONLY = nm.NOTMUCH_DATABASE_MODE_READ_ONLY
+MODE_READ_WRITE = nm.NOTMUCH_DATABASE_MODE_READ_WRITE
+
+def __init__(self, db):
+if not db:
+raise "Failed to open database"
+self.db = db
+
+@staticmethod
+def create(path):
+return Database(nm.notmuch_database_create(path))
+
+@staticmethod
+def open(path, mode):
+return Database(nm.notmuch_database_open(path, mode))
+
+def close(self):
+nm.notmuch_database_close(self.db)
+
+def get_path(self):
+return nm.notmuch_database_get_path(self.db)
+
+def set_timestamp(self, key, timestamp):
+_handle_status(nm.notmuch_database_set_timestamp(self.db, key, 
timestamp))
+
+def get_timestamp(self, key):
+return 
datetime.fromtimestamp(nm.notmuch_database_get_timestamp(self.db, key))
+
+def add_message(self, filename, me

[notmuch] SWIG (and particularly Python) bindings

[Ben Gamari]

Hey all,

I've been looking at switching away from sup recently to something with
a slightly little less everything-and-the-kitchen-sink philosophy.
Notmuch looks excellent, although it appears that its current front-end
for my editor of choice (vim) is a little lacking in some ways
(operations involving a call to notmuch invariably lock up vi for the
duration of the operation).

Regardless, I thought it might be nice to have access to the notmuch
backend from a language other than C (preferably my high-level language
of choice, python). To this end, I took a few hours today acquainting
myself with SWIG and produced these bindings for Python. Unfortunately,
it doesn't appear that SWIG has particularly good support for
object-oriented C, so the approach I took was using SWIG to generate the
low-level glue, on top of which I wrote a properly structured set of
Python bindings. While I theoretically have full interface coverage,
I unfortunately haven't had a chance to use these for anything useful,
so who knows whether much of it actually works. Regardless, I thought
folks might be interested.

While the bindings are currently in the form of a patch to notmuch
(creating a top-level swig directory in the source tree), they could
certainly be moved out-of-tree if the powers that be don't feel it
appropriate to include them. Unfortunately, the build system is
currently almost entirely independent from the notmuch build system. If
these are to be included in-tree, I would be curious to hear people have
to say about how we might integrate it into the sup build system.

Hope this helps someone. I'll hopefully have a chance to work with the
bindings soon and will send a new set of patches once I think I've found
all of the obvious issues.

- Ben


---
 swig/Makefile|   18 
 swig/notmuch.py  |  222 ++
 swig/notmuch_funcs.i |9 ++
 3 files changed, 249 insertions(+), 0 deletions(-)
 create mode 100644 swig/Makefile
 create mode 100644 swig/notmuch.py
 create mode 100644 swig/notmuch_funcs.i

diff --git a/swig/Makefile b/swig/Makefile
new file mode 100644
index 000..c01c427
--- /dev/null
+++ b/swig/Makefile
@@ -0,0 +1,18 @@
+include ../Makefile.config
+
+INCLUDES=-I../lib -I/usr/include/python2.6
+CFLAGS=${INCLUDES}
+
+all : python
+
+python : _notmuch_funcs.so notmuch.py
+
+_notmuch_funcs.so : notmuch_funcs_wrap.o
+   g++ -shared ${XAPIAN_LDFLAGS} ${GMIME_LDFLAGS} ${TALLOC_LDFLAGS} -o $@ 
$< ../lib/notmuch.a
+
+%_wrap.o : %_wrap.c
+   gcc ${CFLAGS} -fPIC -c -o $@ $<
+
+%_wrap.c %.py : %.i 
+   swig -python ${INCLUDES} $<
+
diff --git a/swig/notmuch.py b/swig/notmuch.py
new file mode 100644
index 000..95b81ad
--- /dev/null
+++ b/swig/notmuch.py
@@ -0,0 +1,222 @@
+import notmuch_funcs as nm
+from datetime import datetime
+
+class Exception(Exception):
+def get_message():
+errors = {
+nm.NOTMUCH_STATUS_OUT_OF_MEMORY: 'out of memory',
+nm.NOTMUCH_STATUS_READONLY_DATABASE: 'database opened 
as read-only',
+nm.NOTMUCH_STATUS_XAPIAN_EXCEPTION: 'xapian error',
+nm.NOTMUCH_STATUS_FILE_ERROR: 'file error',
+nm.NOTMUCH_STATUS_FILE_NOT_EMAIL: 'file not email 
message',
+nm.NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: 'duplicate 
message id',
+nm.NOTMUCH_STATUS_NULL_POINTER: 'null pointer',
+nm.NOTMUCH_STATUS_TAG_TOO_LONG: 'tag name too long',
+nm.NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW: 'unbalanced 
freeze/thaw',
+}
+return errors.get(self.status, 'unknown error')
+
+def __init__(self, status):
+self.status = status
+
+def _handle_status(status):
+if (status != nm.NOTMUCH_STATUS_SUCCESS):
+raise Exception(status)
+
+class Database(object):
+MODE_READ_ONLY = nm.NOTMUCH_DATABASE_MODE_READ_ONLY
+MODE_READ_WRITE = nm.NOTMUCH_DATABASE_MODE_READ_WRITE
+
+def __init__(self, db):
+if not db:
+raise "Failed to open database"
+self.db = db
+
+@staticmethod
+def create(path):
+return Database(nm.notmuch_database_create(path))
+
+@staticmethod
+def open(path, mode):
+return Database(nm.notmuch_database_open(path, mode))
+
+def close(self):
+nm.notmuch_database_close(self.db)
+
+def get_path(self):
+return nm.notmuch_database_get_path(self.db)
+
+def set_timestamp(self, key, timestamp):
+_handle_status(nm.notmuch_database_set_timestamp(self.db, key, 
timestamp))
+
+def get_timestamp(self, key):
+return 
datetime.fromtimestamp(nm.notmuch_database_get_timestamp(self.db, key))
+
+def add_message(self, filename, me