#email #notmuch


Rust interface and bindings for notmuch

23 releases

Uses old Rust 2015

0.6.0 Nov 16, 2019
0.5.0 Dec 23, 2018
0.4.2 Dec 13, 2018
0.4.1 Nov 7, 2018
0.0.9 Mar 27, 2018

#14 in Email

Download history 23/week @ 2021-06-26 12/week @ 2021-07-03 17/week @ 2021-07-10 47/week @ 2021-07-17 40/week @ 2021-07-24 125/week @ 2021-07-31 23/week @ 2021-08-07 234/week @ 2021-08-14 64/week @ 2021-08-21 31/week @ 2021-08-28 19/week @ 2021-09-04 22/week @ 2021-09-11 18/week @ 2021-09-18 40/week @ 2021-09-25 15/week @ 2021-10-02 42/week @ 2021-10-09

566 downloads per month
Used in 3 crates (2 directly)




This is not much more than a wrapper for the notmuch C api.

Build Status Crate version Download statistics License Join the chat at https://gitter.im/notmuch-rs/Lobby


notmuch-rs expects libnotmuch development files to be installed on your system.


Add this to your Cargo.toml:

notmuch = "*"

and this to your crate root:

extern crate notmuch;


extern crate notmuch;

fn main() {

    let mut mail_path = std::env::home_dir().unwrap();

    let db = notmuch::Database::open(&mail_path, notmuch::DatabaseMode::ReadOnly).unwrap();
    let query = db.create_query("").unwrap();
    let mut threads = query.search_threads().unwrap();

    for thread in threads {
        println!("thread {:?} {:?}", thread.subject(), thread.authors());


Notmuch makes no claims regarding thread safety. It does not seem to use any thread locals, but I did not spot any locks. So, as far as I am concerned, it is not thread safe.
So why do all structs implement Send and Sync? Well, it is safe to access pointers from different threads (as long as you know what you are doing :) ). Up till now I haven't done a lot of multithreaded stuff with notmuch-rs. If you feel this is too permissive, let me know.


All structs are strictly linked together with their lifetime. The root of the tree is Database, which has a lifetime that must outlive any child objects, for instance Query. The Threads iterator that you can get from a Query is always outlived by the parent query. The Threads does not own any individual Thread. These are bound to the owner of the Threads iterator itself. Each structure keeps a PhantomCow marker for its owner.

Typically, using a lifetimes structure like this in an application poses significant difficulties in satisfying these lifetime requirements. While other libraries force the application developers towards crates like owningref or rental to get around this, notmuch-rs makes use of the excellent Supercow, to alleviate this.

This way, you get to choose your own container type, and even keep the parent object alive so you don't have to juggle lifetimes. To use this, most types are accompagnied with an *Ext trait, that accepts Rc, Arc or comparable.

    use std::sync::Arc;
    use notmuch::{DatabaseExt};

    let query = {
        let dbr = Arc::new(db);

        <Database as DatabaseExt>::create_query(dbr.clone(), &"".to_string()).unwrap()


notmuch-rs started out from the following projects:

Any contributions are welcome!