[PATCH gnupgpy 0/5] Modernize python build for gpgmepy

[Ingo Klöcker]

On Sonntag, 23. März 2025 23:47:14 Mitteleuropäische Normalzeit Lucas Hoffmann 
via Gnupg-devel wrote:
> These patches modernize the build process for the gpgmepy repository.
> This was suggested in message 2807036.QOukoFCf94 at daneel
> (https://lists.gnupg.org/pipermail/gnupg-devel/2025-March/035822.html).

Thanks! I have applied the first 4 patches. I haven't applied the fifth patch 
with changes of the m4 files because we want to keep those files as close as 
possible to the upstream versions (python.m4 from automake package and 
ax_python_devel.m4 from the GNU Autoconf Archive). Sorry!

> Some notes about the individual patches:
> 
> - I tried to move as much metadata from the setup.py(.in) file to the
>   pyproject.toml file because it is static in two senses:  It is not
>   touched by configure and friends and it can be parsed without
>   executing it.  I consider both of these advantages for project
>   metadata.

Agreed.

> - I specified the minimum python version as 3.6.  From the message of
>   1a7b204dedaf99efa08915ee561523997175380c it seems that 3.6 was kept
>   because it is supported by some Linux distros.  Otherwise a good list
>   of versions to support would be the versions supported upstream:
>   https://devguide.python.org/versions/ Is there some spelled out policy
>   which python versions should be supported?  Should the project have
>   one?

I don't think we have written down a policy for this. Maybe we should write it 
down somewhere. I think we want to support the versions that are supported 
upstream. Additionally, we may support versions that are shipped with some 
important LTS distros (RHEL? SLES?) in a best-effort manner, i.e. we won't 
actively remove those versions from the list of versions the configure script 
looks for.

> - I do not know the m4 macro language and just made the commit "Remove
>   distutils related code from configure macros" based on my knowledge of
>   shell and python.  I tested the change by running configure on my
>   machine.

Sorry for the work you put into this.

> I tried to search for related issues and patches on the bug tracker but
> only found https://dev.gnupg.org/D545 which seems to be partially
> applied by a7cfdab46f853397794575307a817982cdd06880.  Did I miss any
> important issues or patches that could be incorporated into this series?

I'm not aware of any.

> I tested my changes on my machine by running `make distclean &&
> ./configure --enable-maintainer-mode && make check`.  All but one tests
> pass; the test t-verify.py is reported twice as failure.  This is the
> same on master and with these patches.  Is there some kind of CI or
> defined testing environment (docker container, VM, etc) that I can use?

`make distcheck` usually works well.

> Is this test known to fail or is this a problem with my setup (I am on
> nixos if it matters)?

Here `make distcheck` passed with Python 3.11, 3.12, 3.13 and against master 
builds of libgpg-error and gpgme.

Thanks again for your contribution! I guess next I should look into merging 
the not yet applied changes from https://dev.gnupg.org/D545 . Or do you want 
to look into this? I would appreciate it.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250328/53af5ff9/attachment.sig>