Re: Python3 cffi bindings
On Fri, Oct 16, 2020 at 9:19 AM Gaute Hope wrote: > On Wed, Oct 14, 2020 at 10:24 PM Floris Bruynooghe wrote: > >> Hi Gaute, >> >> On Thu 08 Oct 2020 at 10:13 +0200, Gaute Hope wrote: >> > I made another attempt at porting lieer to notmuch2, but I am missing >> the >> > get_directory method still. Any plans to look at it? >> >> Would indeed be good to add this sometime. I'm still curious to how you >> use it though to make sure 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? >> > > That is correct, as well as relying on an exception if the input directory > is not in the notmuch database. I also use `db.get_path()` to figure out > the relative path w.r.t to the database root, for use in `path:` queries ( > https://github.com/gauteh/lieer/blob/master/lieer/gmailieer.py#L315). > > Re-read the rest of the old thread, and I think you are right that I only need to use `db.get_path()` to do what I need. So that makes this issue less critical for me I guess. -- gaute ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Python3 cffi bindings
On Wed, Oct 14, 2020 at 10:24 PM Floris Bruynooghe wrote: > Hi Gaute, > > On Thu 08 Oct 2020 at 10:13 +0200, Gaute Hope wrote: > > I made another attempt at porting lieer to notmuch2, but I am missing the > > get_directory method still. Any plans to look at it? > > Would indeed be good to add this sometime. I'm still curious to how you > use it though to make sure 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? > That is correct, as well as relying on an exception if the input directory is not in the notmuch database. I also use `db.get_path()` to figure out the relative path w.r.t to the database root, for use in `path:` queries ( https://github.com/gauteh/lieer/blob/master/lieer/gmailieer.py#L315). Regards, Gaute ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Python3 cffi bindings
Hi Gaute, On Thu 08 Oct 2020 at 10:13 +0200, Gaute Hope wrote: > I made another attempt at porting lieer to notmuch2, but I am missing the > get_directory method still. Any plans to look at it? Would indeed be good to add this sometime. I'm still curious to how you use it though to make sure 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 at 6:14 PM Floris Bruynooghe wrote: > >> Hi Gaute, >> >> Thanks for trying this out! >> >> On Mon 04 Nov 2019 at 11:27 +0100, Gaute Hope wrote: >> > I just checked out the wip/cffi branch on git.notmuch.org with the >> > purpose of porting Lieer (https://github.com/gauteh/lieer). There >> > seems to be some missing functionality: `Database.get_directory()` >> > specifically. >> >> Yeah, I didn't add that yet because I don't fully understand how it >> should be used. Specifically I don't know where one might get a >> pathname from to pass to .get_directory() and thus whether the API would >> be cleaner to just return a reasonable directory object from whatever >> location that might be. Maybe notmuch_database_get_path() is the only >> entrypoint here and you can get further by listing files and directories >> from it? But maybe people then use the filesystem directly to find a >> directory and create the directories ad-hoc. >> >> I grepped lieer but I think you only use it in one place? And if I >> understand it correctly you only do this to check if your mailstore/cwd >> is inside the notmuch database. I.e. this is equivalent to checking if >> your mailstore/cwd has notmuch2.Database.path as prefix which you could >> easily do directly rather than using the FileError exception from >> .get_directory(). >> >> So is anyone else aware of some code which uses db.get_directory() to >> give an idea of how and why this is used? >> >> > I also ran into a couple of warning when building >> > (included below). >> >> Thanks for pointing these out. I guess if the bindings are in the main >> repo only the latest library version can be supported without any >> further concerns. >> >> > By the way, it does not seem that the API is very far from the >> > previous python API. If it is close enough, perhaps it is possible to >> > get away with a bug version bump in the bindings rather than creating >> > a new package. I understand the need for a new package, but it would >> > be nice if we could avoid the future confusion of two python binding >> > packages (if at all possible). >> >> While I'm glad to hear that you think a migration wouldn't be to painful >> for you I am very weary of knowingly breaking APIs. I'd rather have >> people have an easy migration rather than unexpected breakage after an >> upgrade. >> >> >> Cheers, >> Floris >> ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Python3 cffi bindings
Hi Floris and others, I made another attempt at porting lieer to notmuch2, but I am missing the get_directory method still. Any plans to look at it? Regards, Gaute On Sun, Nov 17, 2019 at 6:14 PM Floris Bruynooghe wrote: > Hi Gaute, > > Thanks for trying this out! > > On Mon 04 Nov 2019 at 11:27 +0100, Gaute Hope wrote: > > I just checked out the wip/cffi branch on git.notmuch.org with the > > purpose of porting Lieer (https://github.com/gauteh/lieer). There > > seems to be some missing functionality: `Database.get_directory()` > > specifically. > > Yeah, I didn't add that yet because I don't fully understand how it > should be used. Specifically I don't know where one might get a > pathname from to pass to .get_directory() and thus whether the API would > be cleaner to just return a reasonable directory object from whatever > location that might be. Maybe notmuch_database_get_path() is the only > entrypoint here and you can get further by listing files and directories > from it? But maybe people then use the filesystem directly to find a > directory and create the directories ad-hoc. > > I grepped lieer but I think you only use it in one place? And if I > understand it correctly you only do this to check if your mailstore/cwd > is inside the notmuch database. I.e. this is equivalent to checking if > your mailstore/cwd has notmuch2.Database.path as prefix which you could > easily do directly rather than using the FileError exception from > .get_directory(). > > So is anyone else aware of some code which uses db.get_directory() to > give an idea of how and why this is used? > > > I also ran into a couple of warning when building > > (included below). > > Thanks for pointing these out. I guess if the bindings are in the main > repo only the latest library version can be supported without any > further concerns. > > > By the way, it does not seem that the API is very far from the > > previous python API. If it is close enough, perhaps it is possible to > > get away with a bug version bump in the bindings rather than creating > > a new package. I understand the need for a new package, but it would > > be nice if we could avoid the future confusion of two python binding > > packages (if at all possible). > > While I'm glad to hear that you think a migration wouldn't be to painful > for you I am very weary of knowingly breaking APIs. I'd rather have > people have an easy migration rather than unexpected breakage after an > upgrade. > > > Cheers, > Floris > ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Python3 cffi bindings
On Sat, Nov 16 2019, David Bremner wrote: > Gaute Hope writes: > >> >> By the way, it does not seem that the API is very far from the >> previous python API. If it is close enough, perhaps it is possible to >> get away with a bug version bump in the bindings rather than creating >> a new package. I understand the need for a new package, but it would >> be nice if we could avoid the future confusion of two python binding >> packages (if at all possible). >> > > I'm not in a good position to judge how similar the APIs are. It does > seem like there are at least some breaking changes, and we usually try > to make things smooth for people upgrading by deprecating interfaces > before removing them completely. On the other hand our previous concern > for supporting python pre 3.6 (I think. Maybe 3.5?) seems less and less > worrying (except maybe for people using old CentOS like things). Currently such a recent Linux distribution as Ubuntu 16.04 LTS is not new enough to be used as is when compiling latest notmuch from git (or 0.29), as GMIME 3.0 is required (Ubuntu 16.04 ships GMIME 2.6 and Python 3.5). GMIME 2.6 was pretty easy to compile, GMIME 3 is a bit harder... Ubuntu 16.04 LTS ships python 3.5 -- and compiling later Pythons is easier than GMIME 3 (done both, GMIME 3 on CentOS 6, Python 3.7 on CentOS 7). So, IMO not supporting python pre 3.6 is fine, as we already reguire gmime 3 and probably soon xapian 1.4 -- distros that ship gmime3 most probably already ship python 3.6... Tomi > > d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
On Sun, Nov 17, 2019 at 6:14 PM Floris Bruynooghe wrote: > > Hi Gaute, > > Thanks for trying this out! > > On Mon 04 Nov 2019 at 11:27 +0100, Gaute Hope wrote: > > I just checked out the wip/cffi branch on git.notmuch.org with the > > purpose of porting Lieer (https://github.com/gauteh/lieer). There > > seems to be some missing functionality: `Database.get_directory()` > > specifically. > > Yeah, I didn't add that yet because I don't fully understand how it > should be used. Specifically I don't know where one might get a > pathname from to pass to .get_directory() and thus whether the API would > be cleaner to just return a reasonable directory object from whatever > location that might be. Maybe notmuch_database_get_path() is the only > entrypoint here and you can get further by listing files and directories > from it? But maybe people then use the filesystem directly to find a > directory and create the directories ad-hoc. If I understand correctly then these are the directories known to notmuch db, so may not correspond to filesystem. Lieer do not modify Directory objects directly, but others might. > I grepped lieer but I think you only use it in one place? And if I > understand it correctly you only do this to check if your mailstore/cwd > is inside the notmuch database. I.e. this is equivalent to checking if > your mailstore/cwd has notmuch2.Database.path as prefix which you could > easily do directly rather than using the FileError exception from > .get_directory(). Yes, I think that would work here. I need the path of the directory later (for the path:.. query). Seems that the current python API removes the leading path of the database for the argument to notmuch_database_get_directory(..) -- at least if the notmuch API docs are correct. I had some reported issues with symlinked directories and absolute paths, but I don't think any of that would be influenced by changes like these. Regards, Gaute ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
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()` > specifically. Yeah, I didn't add that yet because I don't fully understand how it should be used. Specifically I don't know where one might get a pathname from to pass to .get_directory() and thus whether the API would be cleaner to just return a reasonable directory object from whatever location that might be. Maybe notmuch_database_get_path() is the only entrypoint here and you can get further by listing files and directories from it? But maybe people then use the filesystem directly to find a directory and create the directories ad-hoc. I grepped lieer but I think you only use it in one place? And if I understand it correctly you only do this to check if your mailstore/cwd is inside the notmuch database. I.e. this is equivalent to checking if your mailstore/cwd has notmuch2.Database.path as prefix which you could easily do directly rather than using the FileError exception from .get_directory(). So is anyone else aware of some code which uses db.get_directory() to give an idea of how and why this is used? > I also ran into a couple of warning when building > (included below). Thanks for pointing these out. I guess if the bindings are in the main repo only the latest library version can be supported without any further concerns. > By the way, it does not seem that the API is very far from the > previous python API. If it is close enough, perhaps it is possible to > get away with a bug version bump in the bindings rather than creating > a new package. I understand the need for a new package, but it would > be nice if we could avoid the future confusion of two python binding > packages (if at all possible). While I'm glad to hear that you think a migration wouldn't be to painful for you I am very weary of knowingly breaking APIs. I'd rather have people have an easy migration rather than unexpected breakage after an upgrade. Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
Gaute Hope writes: > > By the way, it does not seem that the API is very far from the > previous python API. If it is close enough, perhaps it is possible to > get away with a bug version bump in the bindings rather than creating > a new package. I understand the need for a new package, but it would > be nice if we could avoid the future confusion of two python binding > packages (if at all possible). > I'm not in a good position to judge how similar the APIs are. It does seem like there are at least some breaking changes, and we usually try to make things smooth for people upgrading by deprecating interfaces before removing them completely. On the other hand our previous concern for supporting python pre 3.6 (I think. Maybe 3.5?) seems less and less worrying (except maybe for people using old CentOS like things). d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
Hi,
I just checked out the wip/cffi branch on git.notmuch.org with the
purpose of porting Lieer (https://github.com/gauteh/lieer). There
seems to be some missing functionality: `Database.get_directory()`
specifically. I also ran into a couple of warning when building
(included below).
Thanks for your work.
By the way, it does not seem that the API is very far from the
previous python API. If it is close enough, perhaps it is possible to
get away with a bug version bump in the bindings rather than creating
a new package. I understand the need for a new package, but it would
be nice if we could avoid the future confusion of two python binding
packages (if at all possible).
Regards, Gaute
~/dev/notm/notmuch/bindings/python-cffi wip/cffi
notm ❯ python setup.py build
warning: no previously-included files found matching 'setup.pyc'
warning: no previously-included files matching 'yacctab.*' found under
directory 'tests'
warning: no previously-included files matching 'lextab.*' found under
directory 'tests'
warning: no previously-included files matching 'yacctab.*' found under
directory 'examples'
warning: no previously-included files matching 'lextab.*' found under
directory 'examples'
zip_safe flag not set; analyzing archive contents...
pycparser.ply.__pycache__.lex.cpython-37: module references __file__
pycparser.ply.__pycache__.lex.cpython-37: module MAY be using
inspect.getsourcefile
pycparser.ply.__pycache__.yacc.cpython-37: module references __file__
pycparser.ply.__pycache__.yacc.cpython-37: module MAY be using
inspect.getsourcefile
pycparser.ply.__pycache__.yacc.cpython-37: module MAY be using inspect.stack
pycparser.ply.__pycache__.ygen.cpython-37: module references __file__
Installed
/home/gauteh/dev/notm/notmuch/bindings/python-cffi/.eggs/pycparser-2.19-py3.7.egg
running build
running build_py
creating build
creating build/lib.linux-x86_64-3.7
creating build/lib.linux-x86_64-3.7/notdb
copying notdb/_message.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/__init__.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_database.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_errors.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_tags.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_thread.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_query.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_build.py -> build/lib.linux-x86_64-3.7/notdb
copying notdb/_base.py -> build/lib.linux-x86_64-3.7/notdb
running build_ext
generating cffi module 'build/temp.linux-x86_64-3.7/notdb._capi.c'
creating build/temp.linux-x86_64-3.7
building 'notdb._capi' extension
creating build/temp.linux-x86_64-3.7/build
creating build/temp.linux-x86_64-3.7/build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3
-Wall -fPIC -I../../lib
-I/home/gauteh/.pyenv/versions/3.7.4/envs/notm/include
-I/home/gauteh/.pyenv/versions/3.7.4/include/python3.7m -c
build/temp.linux-x86_64-3.7/notdb._capi.c -o
build/temp.linux-x86_64-3.7/build/temp.linux-x86_64-3.7/notdb._capi.o
build/temp.linux-x86_64-3.7/notdb._capi.c: In function
‘_cffi_d_notmuch_database_add_message’:
build/temp.linux-x86_64-3.7/notdb._capi.c:980:3: warning:
‘notmuch_database_add_message’ is deprecated: function deprecated as
of libnotmuch 5.1 [-Wdeprecated-declarations]
return notmuch_database_add_message(x0, x1, x2);
^~
In file included from build/temp.linux-x86_64-3.7/notdb._capi.c:495:0:
../../lib/notmuch.h:637:1: note: declared here
notmuch_database_add_message (notmuch_database_t *database,
^~~~
build/temp.linux-x86_64-3.7/notdb._capi.c: In function
‘_cffi_f_notmuch_database_add_message’:
build/temp.linux-x86_64-3.7/notdb._capi.c:1033:3: warning:
‘notmuch_database_add_message’ is deprecated: function deprecated as
of libnotmuch 5.1 [-Wdeprecated-declarations]
{ result = notmuch_database_add_message(x0, x1, x2); }
^
In file included from build/temp.linux-x86_64-3.7/notdb._capi.c:495:0:
../../lib/notmuch.h:637:1: note: declared here
notmuch_database_add_message (notmuch_database_t *database,
^~~~
gcc -pthread -shared -L/home/gauteh/.pyenv/versions/3.7.4/lib
-L/home/gauteh/.pyenv/versions/3.7.4/lib
build/temp.linux-x86_64-3.7/build/temp.linux-x86_64-3.7/notdb._capi.o
-L../../lib -lnotmuch -o
build/lib.linux-x86_64-3.7/notdb/_capi.abi3.so
On Tue, Oct 8, 2019 at 11:03 PM Floris Bruynooghe wrote:
>
> 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 things work, updated tests on new
> python versions, added a very basic intergration with the test
> framework and squashed the commits. Otherwise the attached patch
> is just a plain dump of the current state so interested people have
>
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 --git a/bindings/python-cffi/tests/conftest.py
>> b/bindings/python-cffi/tests/conftest.py
>> index 1b7bbc35..ac17397c 100644
>> --- a/bindings/python-cffi/tests/conftest.py
>> +++ b/bindings/python-cffi/tests/conftest.py
>> @@ -31,7 +31,7 @@ def notmuch(maildir):
>> accidentally do this in the unittests.
>> """
>> cfg_fname = maildir.path / 'notmuch-config'
>> -cmd = ['notmuch'] + list(args)
>> +cmd = ['../../notmuch'] + list(args)
>> print('Invoking: {}'.format(' '.join(cmd)))
>> proc = subprocess.run(cmd,
>>
>
> I think I figured it out. Your 'run' function completely overrides the
> environment. But just adding PATH back seems to do the trick. I'm not
> sure if this is the most idomatic change, but it works:
>
> diff --git a/bindings/python-cffi/tests/conftest.py
> b/bindings/python-cffi/tests/conftest.py
> index 1b7bbc35..6a81aa18 100644
> --- a/bindings/python-cffi/tests/conftest.py
> +++ b/bindings/python-cffi/tests/conftest.py
> @@ -33,9 +33,11 @@ def notmuch(maildir):
> cfg_fname = maildir.path / 'notmuch-config'
> cmd = ['notmuch'] + list(args)
> print('Invoking: {}'.format(' '.join(cmd)))
>proc = subprocess.run(cmd,
>timeout=5,
> - env={'NOTMUCH_CONFIG': str(cfg_fname)})
> +
> env={'PATH':os.environ["PATH"],'NOTMUCH_CONFIG': str(cfg_fname)})
> proc.check_returncode()
> return run
>
This seems reasonable, perhaps even a "env = os.environ.copy();
env['NOTMUCH_CONFIG'] = src(cfg_fname)" is better here so that
LD_LIBRARY_PATH and anything else is kept around.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
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 --git a/bindings/python-cffi/tests/conftest.py
> b/bindings/python-cffi/tests/conftest.py
> index 1b7bbc35..ac17397c 100644
> --- a/bindings/python-cffi/tests/conftest.py
> +++ b/bindings/python-cffi/tests/conftest.py
> @@ -31,7 +31,7 @@ def notmuch(maildir):
> accidentally do this in the unittests.
> """
> cfg_fname = maildir.path / 'notmuch-config'
> -cmd = ['notmuch'] + list(args)
> +cmd = ['../../notmuch'] + list(args)
> print('Invoking: {}'.format(' '.join(cmd)))
> proc = subprocess.run(cmd,
>
I think I figured it out. Your 'run' function completely overrides the
environment. But just adding PATH back seems to do the trick. I'm not
sure if this is the most idomatic change, but it works:
diff --git a/bindings/python-cffi/tests/conftest.py
b/bindings/python-cffi/tests/conftest.py
index 1b7bbc35..6a81aa18 100644
--- a/bindings/python-cffi/tests/conftest.py
+++ b/bindings/python-cffi/tests/conftest.py
@@ -33,9 +33,11 @@ def notmuch(maildir):
cfg_fname = maildir.path / 'notmuch-config'
cmd = ['notmuch'] + list(args)
print('Invoking: {}'.format(' '.join(cmd)))
proc = subprocess.run(cmd,
timeout=5,
- env={'NOTMUCH_CONFIG': str(cfg_fname)})
+ env={'PATH':os.environ["PATH"],'NOTMUCH_CONFIG':
str(cfg_fname)})
proc.check_returncode()
return run
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
Floris Bruynooghe writes:
>
> It is possible to run this without installing, but it does need a build
> step since cffi (in the mode used - which is the recommended mode) needs
> to build an extension module. I did something like this, using my
> debian testing system-installed python
>
> $ export PYTHONPATH=$(pwd)/bindings/python-cffi
> $ pushd bindings/python-cffi
> $ python3 notdb/_build.py # creates
> notdb/_capi.cpython-37m-x86_64-linux-gnu.so
> $ popd
> $ pushd test
> $ ./T391-pytest.sh
Yes, I think I arrived at a similar place, except
1) using "python3 setup.py --build-lib build/stage" to build. I'm not
sure which is better, I think it will depend a bit on when we try to get
out of tree builds working. It is a bit nicer to have the build output
out of tree, but then I have to copy the tests.
2) instead of changing PYTHONPATH, use "python3 -m pytest", which picks
up the module in the current directory.
> Does that more or less work? One problem with this is that it will pick
> up the system-wide installed notmuch though. I guess the way to change
> this is by tweaking CFLAGS=-I... LDFLAGS=-L... or so when building? But
> than you also have the whole RPATH/LD_LIBRARY_PATH stuff going on as
> well. Does notmuch abstract any of this away already for it's test
> suite?
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 --git a/bindings/python-cffi/tests/conftest.py
b/bindings/python-cffi/tests/conftest.py
index 1b7bbc35..ac17397c 100644
--- a/bindings/python-cffi/tests/conftest.py
+++ b/bindings/python-cffi/tests/conftest.py
@@ -31,7 +31,7 @@ def notmuch(maildir):
accidentally do this in the unittests.
"""
cfg_fname = maildir.path / 'notmuch-config'
-cmd = ['notmuch'] + list(args)
+cmd = ['../../notmuch'] + list(args)
print('Invoking: {}'.format(' '.join(cmd)))
proc = subprocess.run(cmd,
then the tests pass, but this is obviously not a good solution.
test.output.xz
Description: application/xz
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
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 `pip -e .`. > I should have mentioned that if I manually set python path with > something like > > $ PYTHONPATH=`pwd`/build/lib.linux-x86_64-3.7:$PYTHONPATH pytest-3 > > it works OK. Is there a simple/reliable way of calculating the path > lib.linux-x86_64-3.7? It is possible to run this without installing, but it does need a build step since cffi (in the mode used - which is the recommended mode) needs to build an extension module. I did something like this, using my debian testing system-installed python $ export PYTHONPATH=$(pwd)/bindings/python-cffi $ pushd bindings/python-cffi $ python3 notdb/_build.py # creates notdb/_capi.cpython-37m-x86_64-linux-gnu.so $ popd $ pushd test $ ./T391-pytest.sh Does that more or less work? One problem with this is that it will pick up the system-wide installed notmuch though. I guess the way to change this is by tweaking CFLAGS=-I... LDFLAGS=-L... or so when building? But than you also have the whole RPATH/LD_LIBRARY_PATH stuff going on as well. Does notmuch abstract any of this away already for it's test suite? Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
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. I should have mentioned that if I manually set python path with something like $ PYTHONPATH=`pwd`/build/lib.linux-x86_64-3.7:$PYTHONPATH pytest-3 it works OK. Is there a simple/reliable way of calculating the path lib.linux-x86_64-3.7? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
Floris Bruynooghe writes: > IIRC this probably wants to be renamed to "notmuch2" instead of > "notdb". Otherwise I'm pretty sure this doesn't cover all the > current features either. Yes, I think notmuch2 was the least disliked suggestion. > So maybe this can be used as a start to figure out how to merge > this if there's still an interest in this. I'm interested. The blocker for me at the moment is getting the tests working without tox / venvs. I'm hoping we can test with the system python and the built, but not installed module. I guess we need to build it so that the C extension part is loaded. The shim in T391-python-cffi.sh doesn't work for me, it doesn't manage to set PYTHONPATH so that notdb is importable. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
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. Otherwise the attached patch >> is just a plain dump of the current state so interested people have >> at least a copy of the code again which can be made to work. > > I think you missed the attachement. Other than that, sounds interesting ;). I used git send-email as per the contributing nodes, so it was supposed to be a followup email. It does seem like I got a message back saying the patch mail is being held in the moderator queue as it's too large... Perhaps you have moderation powers? Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
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. Otherwise the attached patch > is just a plain dump of the current state so interested people have > at least a copy of the code again which can be made to work. I think you missed the attachement. Other than that, sounds interesting ;). ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
