Migrate to notmuch2 module

[GuillaumeSeren]

Hello

This is my upgrade of afew to use the notmuch2 module, I tested on my setup the tag and MailMover but more test would be good.

I'd like some review from any motivated user (looking at you @flokli :wink: ).

I think with some more tests and review it could be merged in, because this does not change afew, just upgrade the call to use the new module, no new fancy feature like transaction are enable yet.

[GuillaumeSeren]

I fixed some linting issue, but the actual image on gh action is 18.04, and it doesn't get the module package.

I have tested on 20.04 but the module is packaged from 20.10, from what I can see here -> https://pkgs.org/search/?q=notmuch

Edit: I checked how alot do to get it, they are building notmuch from source, maybe we could do that https://github.com/pazz/alot/blob/master/.travis.yml

[flokli]

Can we use pip and go with the notmuch2 sdist from PyPI, assuming we provide the necessary build dependencies to CI?

[GuillaumeSeren]

Can we use pip and go with the notmuch2 sdist from PyPI, assuming we provide the necessary build dependencies to CI?

Yes probably I have to look into it

[ff2000]

Can we use pip and go with the notmuch2 sdist from PyPI, assuming we provide the necessary build dependencies to CI?

Yes probably I have to look into it

No, please don't. notmuch2 bindings on pypi are not officially supported, also releases stopped with notmuch-0.30-rc1, so you would only use a horrendously outdated notmuch2-binding that probably wouldn't even work properly... I think notmuch config support came later, also support for saved searches.

[flokli]

Then I'd propose closing this till there's a proper release of this in the official package repository.

[GuillaumeSeren]

notmuch2 bindings on pypi are not officially supported

Yes I guessed that.

Then I'd propose closing this till there's a proper release of this in the official package repository.

I understand that, but I think we should follow alot to notmuch2 support, because after talking to a notmuch maintainer the module will be drop at some point.

There are still valid options:

• Finding a PPA that provide that package.
• Compiling from source in the runner (like alot do).

[flokli]

I'd assume there will be a transitional period where both projects will have somewhat-maintained releases. We shouldn't self-inflict pain more than necessary in trying to package it before it's properly released.

The diff in this PR is pretty minimal, so it can be re-rolled at a later point in time.

[flokli]

Also, this PR switches to notmuch2 exclusively, meaning every release containing this will push the burden on packaging an unreleased python module to any downstream packagers. I really don't think we should do this at this time. Let's wait for a proper release on PyPI, then I'm happy to re-roll this.

[ff2000]

I'd assume there will be a transitional period where both projects will have somewhat-maintained releases. We shouldn't self-inflict pain more than necessary in trying to package it before it's properly released. The diff in this PR is pretty minimal, so it can be re-rolled at a later point in time.

notmuch2 bindings were properly released with notmuch-0.30.0. notmuch now is at 0.31.2 notmuch devs officially support debian packages (0.31.2-3 now in debian unstable). pypi package comes from an unofficial fork of the notmuch2 bindings: https://github.com/weilbith/notmuch2-python-bindings And here a short thread on the notmuch mailing list concerning the bindings on pypi: http://notmuch.198994.n3.nabble.com/python-notmuch2-on-PyPI-td4042626.html Hook in if you know how to proceed to get notmuch2 officially released von PyPi

[GuillaumeSeren]

Thank you both for discussing this @flokli @ff2000

This issue is not urgent yet, but I like to know that we have a working poc for it, while it can wait for all the distro to package this, I don't think we should diverge from alot on this subject.

Also, this PR switches to notmuch2 exclusively, meaning every release containing this will push the burden on packaging an unreleased python module to any downstream packagers.

Yes it is bc breaking change, and will require the new notmuch2 module, but he module is present in the tarball source, it is released and most distro already has it, sure when we merge this we should check that most (all) targeted distro have a process to get it.

I really don't think we should do this at this time. Let's wait for a proper release on PyPI, then I'm happy to re-roll this.

Actually there is no 'official support' of pypi release from them, so the main discussion should be 'do we change how we get notmuch ?'

[flokli]

@ff2000 Okay, so we shouldn't use the PyPI packages, but from the official package sources, gotcha.

@GuillaumeSeren python3-notmuch2 only exists in Ubuntu groovy or Debian buster. Shouldn't we at least wait until it's available in Debian Stable?

If you want, you could add a "notmuch2" branch that's rebased on top of master every once and then (with a updated github action to have this package), but I don't really think it's wise to merge this to master any time soon, at least not until python3-notmuch2 has landed in some stable distributions.

[GuillaumeSeren]

@flokli

@ff2000 Okay, so we shouldn't use the PyPI packages, but from the official package sources, gotcha.

Good question, but I would be easyer for us if a official pip version exist.

python3-notmuch2 only exists in Ubuntu groovy or Debian buster. Shouldn't we at least wait until it's available in Debian Stable?

It depends, I think Debian is not notmuch upstream (some of the dev are), and notmuch provide that module in official tarball, so why should we wait instead of switch ? (and also alot use notmuch from git)

If you want, you could add a "notmuch2" branch that's rebased on top of master every once and then

Yes I know but unless there more complex changes to make, let's keep it simple in this PR.

I don't really think it's wise to merge this to master any time soon, at least not until python3-notmuch2 has landed in some stable distributions.

Sure we can wait for the module to be more available to merge this change, I think we should consider switching to an official tarball, the flow should upstream -> distro.