It is unlikely this still works since it has not been updated since
2010. The python packages for debian are now built by the top level
debian/ packaging.
We adopt a pythonic idiom here with an optional argument, rather than
exposing the user to the C indexopts object directly.
This now includes a simple test to ensure that the decrypt_policy
argument works as expected.
The old name has a bit of a feeling of hungarian notation. Also many
generators in the core are named with the suffix "s" to indicate
iterables: dict.items, dict.keys for example.
It makes the function a little more intuitive to use and does not
diverge much from the original function signature.
Also an example is added to the docstring.
The C functions notmuch_database_get_config,
notmuch_database_get_config_list and notmuch_database_set_config are
part of the official C bindings. So there should also be some python
bindings for them.
Also they are the only way to access the named queries introduced in
b9bf3f44.
The interface of the python functions is designed to be close to the C
functions.
currently, notmuch's get_message_parts() opens the file in text mode and passes
the file object to email.message_from_file(fp). In case the email contains
UTF-8 characters, reading might fail inside email.parser with the following exception:
File "/usr/lib/python3.6/site-packages/notmuch/message.py", line 591, in get_message_parts
email_msg = email.message_from_binary_file(fp)
File "/usr/lib/python3.6/email/__init__.py", line 62, in message_from_binary_file
return BytesParser(*args, **kws).parse(fp)
File "/usr/lib/python3.6/email/parser.py", line 110, in parse
return self.parser.parse(fp, headersonly)
File "/usr/lib/python3.6/email/parser.py", line 54, in parse
data = fp.read(8192)
File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 1865: invalid continuation byte
To fix this, read file in binary mode and pass to
email.message_from_binary_file(fp).
Unfortunately, Python 2 doesn't support
email.message_from_binary_file(fp), so keep using
email.message_from_file(fp) there.
Signed-off-by: Florian Klink <flokli@flokli.de>
The deprecated Database.add_message now calls the new index_file with
correct number of arguments (without an extra `self`), and returns the
tuple from index_file - as it used to do before.
This change also adds a DeprecationWarning to the function.
We need a way to pass parameters to the indexing functionality on the
first index, not just on reindexing. The obvious place is in
notmuch_database_add_message. But since modifying the argument list
would break both API and ABI, we needed a new name.
I considered notmuch_database_add_message_with_params(), but the
functionality we're talking about doesn't always add a message. It
tries to index a specific file, possibly adding a message, but
possibly doing other things, like adding terms to an existing message,
or failing to deal with message objects entirely (e.g. because the
file didn't contain a message).
So i chose the function name notmuch_database_index_file.
I confess i'm a little concerned about confusing future notmuch
developers with the new name, since we already have a private
_notmuch_message_index_file function, and the two do rather different
things. But i think the added clarity for people linking against the
future libnotmuch and the capacity for using index parameters makes
this a worthwhile tradeoff. (that said, if anyone has another name
that they strongly prefer, i'd be happy to go with it)
This changeset also adjusts the tests so that we test whether the new,
preferred function returns bad values (since the deprecated function
just calls the new one).
We can keep the deprecated n_d_add_message function around as long as
we like, but at the next place where we're forced to break API or ABI
we can probably choose to drop the name relatively safely.
NOTE: there is probably more cleanup to do in the ruby and go bindings
to complete the deprecation directly. I don't know those languages
well enough to attempt a fix; i don't know how to test them; and i
don't know the culture around those languages about API additions or
deprecations.
A leading / in paths in a .gitignore file matches the beginning of the
path, meaning that for patterns without slashes, git will match files
only in the current directory as opposed to in any subdirectory.
Prefix relevant paths with / in .gitignore files, to prevent
accidentally ignoring files in subdirectories and possibly slightly
improve the performance of "git status".
This function was deprecated in notmuch 0.21. We re-use the name for
a status returning version, and deprecate the _st name. One or two
remaining uses of the (removed) non-status returning version fixed at
the same time
This function was deprecated in notmuch 0.21. We finally remove the
deprecated API, and rename the status returning version to the simpler
name. The status returning is kept as a deprecated alias.
In addition to use ${srcdir} and deliver ${NOTMUCH_SRCDIR} where needed,
source from ruby bindings had to be copied to the out-of-tree target
directory -- if the source files in source directory were referenced
in build and there were also built object files there, those could have
been considered as target files (and then not found when attempting
to create bindings/ruby/notmuch.so).
This signals two things, an intent to be more liberal about accepting
patches, and an intent to stop distributing the bindings if maintenance
doesn't pick up.
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
Currently, http://packages.python.org/notmuch/ goes through a series
of redirections and ends up pointing to readthedocs. Since we're
using readthedocs directly anyway, just point to it directly.
readthedocs are also now sensibly using a separate domain
(readthedocs.io) for their hosted documentation as distinct from their
own domain (readthedocs.org), so use the correct tld.
The Ruby bindings were missing a way to get all the tags of the
database. Now you should be able to access this with the public
instance method `all_tags` of your database object.
Example of use:
notmuchdb = Notmuch::Database.new path, { :create => false,
:mode => Notmuch::MODE_READ_ONLY }
my_tags = notmuchdb.all_tags
my_tags.each { |tag|
print tag
}
my_tags.destroy!
Amended by db: improve error reporting, add test
The usual make message on everything being up to date is:
make: Nothing to be done for 'all'.
However, since
commit d038b93209
Author: David Bremner <david@tethera.net>
Date: Mon Jun 1 09:08:59 2015 +0200
build: integrate building ruby bindings into notmuch build process
if one doesn't have the ruby dependencies installed, the message has
been:
Missing dependency, skipping ruby bindings
Restore the usual behaviour by dropping the message. It's redundant
during build anyway, since the configure script already outputs:
Checking for ruby development files... No (skipping ruby bindings)
The notmuch python bindings document that database.remove_message
should raise an exception when the message removal fails, but they
don't actually do it.
Drop unused imports, and avoid warning about unused imports when we
import something on behalf of another module.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
Remove the __len__ functions, as they exhaust the iterator, breaking
'list(x)'.
This is a follow-up to 8866a89e.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
Use 'notmuch_query_search_{threads,messages}_st' instead of their
deprecated counterpart.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
Add support for the new notmuch status codes UNSUPPORTED_OPERATION,
UPGRADE_REQUIRED, and PATH_ERROR.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
This gives some additional access to debugging information when using
the python bindings.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
This is supposed to help build on systems like MacOS with different
conventions for naming shared libraries. We have already computed the
relevant names, so doing it again in ruby seems like a bad idea.
Because ruby generates a Makefile, we have to use recursive make.
Because mkmf.rb hardcodes the name Makefile, put our Makefile{.local}
in the parent directory.
Failing to update this string in globals.py causes failures when the
SONAME changes. In order to hopefully reduce the number of such
errors, automate the process of setting the SONAME in the python
bindings.
