Switch from gpg to python-gnupg

[meeuw]

Is your feature request related to a problem? Please describe.
https://pypi.org/project/gpg/ hasn't been updated since 2018. I have trouble installing it because it fails with the following error:

Using gpgme.h from /usr/include/gpgme.h
Deprecated command line option: -py3. Ignored, this option is no longer supported.
build/gpgme.h:16: Error: CPP #error ""unexpected value for __WORDSIZE macro"". Use the -cpperraswarn option to continue swig processing.
error: command '/usr/bin/swig' failed with exit code 1

Describe the solution you'd like
Switch to python-gnupg which seems to be better maintained.

Describe alternatives you've considered
Make gpg optional in alot. (I'm currently not using gpg to sign/encrypt my mail).

Additional context
I noticed that there are tests for the crypto module in alot, I can try to create a PR porting everything to python-gnupg and make all the tests green but first I'd like to check if you agree on this.

[dkg]

I think you're looking at the wrong place for the gpg module in python. This is maintained by the GnuPG upstream as part of gpgme, and has had four releases this calendar year alone.

python-gnupg, by contrast, is developed by someone outside the GnuPG project and has had only one release this calendar year.

[meeuw]

You're right, that works for me, thanks!

It could still make sense to switch to python-gnupg to ease the installation of alot though.

I leave this decision to the maintainer(s) of this project, my offer still stands to port alot to python-gnupg.

[pazz]

@dkg sorry but it seems I am thick: you are the debian maintainer of the libgpgme-dev package: how do you install alot on debian testing? I still cannot install via pip or poetry or the like, because my system is missing the gpgme-config tool as of recently.. any suggestions? (thx)

[pazz]

I am still struggling with this. I agree that it'd be good to depend on the official gnupg bindings but the current (alot) dependencies point to this outdated PIP repository that is not installable on debian as mentioned above.
Two ways forward: Either port to this python-gpgme package as suggested in the OP, or to pester the main gpgme people to take over the PIP entry.. Thoughts?

[lucc]

My gut feeling is to prefer the official gpg package. I would thus vote to "pester the gpg folks".

We have a similar problem with the python notmuch bindings which are also non trivial to install and are not released to PyPI for any recent version. This also came up in #1617.

For me this topic is connected to the question of our build system: are we using setuptools or are we using poetry? We have a pyproject.toml file which specifies

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

but we also have a setup.py file which imports setuptools. If we fully commit to poetry (or setuptools) we could try to specify the dependencies with some upstream git repo (docs for poetry, setuptools seems to be able to do this, too).

(We also have a setup.cfg file but that seems to be an artefact.)

[meeuw]

poetry.lock also locks gpg to a specific version:

alot/poetry.lock

Lines 222 to 230 in e47953a

	[[package]]
	name = "gpg"
	version = "1.10.0"
	description = "Python bindings for GPGME GnuPG cryptography library"
	optional = false
	python-versions = "*"
	files = [
	{file = "gpg-1.10.0.tar.gz", hash = "sha256:349214a866c84aa548bc35ed14eccd2ec9085b3958d5753a63a19a71a1f523ca"},
	]

You can configure poetry to use system site packages using the following poetry.toml:

[virtualenvs.options]
system-site-packages = true

But that required me to remove gpg from pyproject.toml. Not ideal but it works.

[pazz]

I've taken the hammer and hardcoded a dependency for gpg > 1.10.0 now. It is not sustainable to have people keep pulling an old version that is not maintained from pypi.
This is likely going to break any poetry stuff that relies on this package, but honestly: tough. I hope there is enough appetite for developing an alternative that works with pypi/poetry. Otherwise we'll have to tell people to install python gpg by hand,just like notmuch.

[lucc]

@pazz the poetry lock file and the pyproject file are now out of sync. We should update the poetry lock file as well.

https://github.com/pazz/alot/actions/runs/7868562167/job/21465991843

[pazz]

Thanks for the heads-up. I don't really know how poetry works and would be happy to push any such PR (but you have write access anyway). I expect that an easy install via poetry will not work without extra work anyway, as `pip install gpg` will fail now. Thanks (and sorry for the brute-force approach :)) Quoting Lucas Hoffmann (2024-02-12 10:35:29)

…

@pazz the poetry lock file and the pyproject file are now out of sync. We should update the poetry lock file as well. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.*Message ID: <pazz/alot/ ***@***.***>

[meeuw]

I think it's best to remove the poetry lock file, the current lock file doesn't make sense.

[lucc]

I am actually only using 7454b4f from before the gpg>1.10 change. @pazz are you able to build/package alot with any kind of setup (pip,poetry, docker, nix, ...)?

[pazz]

Not really and the reason is that I cannot `pip install` the outdated gpg package from pypi anymore. That change was intended to force people to think about replacing that dependency... Thanks Quoting Lucas Hoffmann (2024-03-18 08:21:55)

…

I am actually only using 7454b4f from before the gpg>1.10 change. @pazz are you able to build/package alot with any kind of setup (pip,poetry, docker, nix, ...)? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.*Message ID: <pazz/alot/ ***@***.***>

[meeuw]

I found this report in the issue tracker at dev.gnupg.org:

https://dev.gnupg.org/T6297

It seems like they are open to the idea of supporting the python bindings on PyPI and have access to the repository.

Python wheels are limited in their design (I have some experience with incompatible openssl versions for a different wheel), I wonder how feasible this will be.

There are other alternatives, how do you people think of:

• Provide a docker image
• Provide a package for Anaconda/conda
• Make GPG optional

[lucc]

There seems to be a new movement upstream to split the python bindings into a separate repo: https://dev.gnupg.org/T7262

This could mean that they might be published to pypi again but at the least it could help in CI as might then be able to install from upstream git with pip.