Mailing List Archive

Hi again,

I noticed a small mistake in the pyproject.toml file that I provided.

Please find attached a revised version, which also properly states the
build-backend for setuptools.

Best,
David

--
https://sleepmap.de

On 2022-11-15 18:37:47 (+0100), David Runge wrote:
> I noticed a small mistake in the pyproject.toml file that I provided.
>
> Please find attached a revised version, which also properly states the
> build-backend for setuptools.

Hi,

does someone have time to review these changes? It would be really great
if they could be included and released.

Without a working version on pypi.org, people trying to use the Python
integration have to host it themselves somehow or rely on system's
packaging (which may not be available depending on OS and does not work
easily for Python's virtual environments).

Best,
David

--
https://sleepmap.de

Hi David,

Am Donnerstag 24 November 2022 00:18:51 schrieb David Runge:
> does someone have time to review these changes? It would be really great
> if they could be included and released.

thanks for sending a contribution!
Eventually someone will review your patches, I just don't know when.
So, they'll be useful for those who find them here.

Have you've done the steps in
https://github.com/gpg/gpgme/blob/master/doc/HACKING#license-policy
yet?

Best Regards,
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

On 2022-11-29 15:05:03 (+0100), Bernhard Reiter wrote:
> So, they'll be useful for those who find them here.

Unfortunately, that is not the case, as Python projects developed in
virtualenvs (arguably a large chunk of today's projects) can not
integrate the existing sdist tarball from pypi.org [1], because it is so
outdated and can not be built/installed.
Adding the PEP517 integration (as done in my patches) is only the
preparation. It is also required that GPGME is released and to push an
up-to-date sdist tarball (which has to be generated by a make target) to
pypi.org (which only the maintainers of this project can do).

In its current state the only way the Python integration can be used is
if one's operating system (e.g. a Linux distribution) provides it as a
package (built alongside gpgme). This renders testing in virtualenvs,
where dependencies can be pinned and built reproducibly impossible
though.

> Have you've done the steps in
> https://github.com/gpg/gpgme/blob/master/doc/HACKING#license-policy
> yet?

Thanks for pointing that out! I had not, but have just sent it.

Best,
David

[1] https://pypi.org/project/gpg/

--
https://sleepmap.de

Hi!

I might be misunderstanding something. However, we do not do anything
with pypi in GnuPG. Thus I can't see what your patch is about. In fact
GPGME comes with its own and different Python language bindings.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 2022-11-30 13:47:30 (+0100), Werner Koch wrote:
> I might be misunderstanding something. However, we do not do anything
> with pypi in GnuPG.

The current available gpg package on pypi.org [1] is an sdist tarball,
generated from gpgme 1.10.0.
The gpgme sources even provide a make target [2] for upload to pypi.org.
It appears that Justus Winter [3] is the person, that last updated and
maintained the sdist tarball for you.

> Thus I can't see what your patch is about.

The 1st patch is about creating an sdist tarball (using the existing
make target) without specifying obsolete options and also allowing the
use of prerelease versions (because Python names them differently - e.g.
1.0.0-alpha -> 1.0.0a).
The 2nd patch is about enabling PEP517 [4] based build backends, which can
use PEP518 [5] based build requirements in a pyproject.toml, to build a
wheel from the sdist tarball on pypi.org.

> In fact GPGME comes with its own and different Python language
> bindings.

As noted above, the sdist tarball on pypi.org was generated from the
gpgme sources (albeit from a very old version) in 2018.

Please reinstate this going forward, as it allows Python projects to use
gpg in virtualenvs (which is a huge chunk of current projects) for
testing and running a project.

Without an up-to-date and functional sdist tarball on pypi.org, projects
can only use system provided packages, which makes projects not be
self-contained and unable to test and run in a Python virtual
environment.

Best,
David

[1] https://pypi.org/project/gpg/
[2] https://github.com/gpg/gpgme/blob/ac4536990a4fed4a45a0851260c029e69d0cadf6/lang/python/Makefile.am#L62-L65
[3] https://pypi.org/user/justus.winter/
[4] https://peps.python.org/pep-0517/
[5] https://peps.python.org/pep-0518/

--
https://sleepmap.de

Hi David,

thanks for sending the DCO
and for caring about the python bindings!

Am Mittwoch 30 November 2022 15:31:15 schrieb David Runge:
> As noted above, the sdist tarball on pypi.org was generated from the
> gpgme sources (albeit from a very old version) in 2018.

I remember that there were a couple of technical and administrative points
which got discussed afterwards and were not fully clarified.
So there is mostly likely a bit of a mess we need to figure out and then clean
up. So your initiative and your explanations are well appreciated.

> Please reinstate this going forward, as it allows Python projects to use
> gpg in virtualenvs (which is a huge chunk of current projects) for
> testing and running a project.

(I guess that folks could still build stuff by themselves, which probably is
considered less practical because of the needed efforts.)

It would be cool to improve the python binding situation,
even it is just to clarify it more.

Regards
Bernhard
--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter